I’ve noticed a couple strange things when using popup menus… I haven’t had time to debug the menu code yet, thought I’d ask first…
I have a “right-click” menu with submenus… when I rollover a menu item which shows a submenu, a strange drawing anomaly occurs: Before the actual submenu appears there is a couple second delay, during which I can see the rect which is the width of the shadow and the height of the submenu redrawn, erased, and then the actual submenu is drawn. This does not happen on the Mac. It makes for a very sluggish menu. With dirty rects on I can see that nothing else is drawing at that time.
I was noticing odd behavior with menus for which I used showAt(screenX, screenY, etc…). It appeared as if the menus were using the bottom right of the menu as the reference point, instead of top left… for example:
…would draw the menu so that it’s bottom right corner (not top left) was at the given coordinates. Apparently:
avoids the problem altogether… but thought I’d mention it anyway.
As a side, does anyone have any suggestions for profiling their Juce app? I see Juce has a PerformanceCounter class… but I was looking for something a little more “robust”.
Well on windows, the shadows are drawn separately to the window, so you could see them appear separately. It’s nothing specific to menus though, and just depends on how long things take to draw, and how the os decides to process the window creation.
showAt doesn’t specify the menu’s top-left - the co-ords should be the position of the mouse or some object that the menu is attached to, and it finds the best spot for the menu based on that. I should probably improve the docs about this.
Thanks, sorry, wasn’t clear to me what the behavior was, but I can see that apparently it is positioned based on where the coordinates are relative to the center of the screen, which I guess makes sense, but my assumption was that it would behave more like the latter where it would draw at the given coordinates and shift only when it hits the edges of the screen.
Perhaps there could be optional flags to specify an anchor and perhaps a “bounds” rect I could give it (relative to some component) within which to shift, scroll or use columns when it hits the edges? In this way, for example, I could confine menus to the main window. Make sense?
Re: 1) I’ll look into it when I have more time… certainly what I’m seeing can’t be normal, or maybe could be avoided somehow.
well, I had a little time today to look at the popupmenu code and sure enuf, it is the shadow windows that are killing me. I thought it was very odd considering my dev machine has a lot of horsepower, and the menus are causing the CPU to spike considerably and slow enough that I get busy cursors.
At any rate I wrote a little wrapper class for the performance counter to time a function call (just creates and starts a pc in the constructor and stops it in destructor, so you just have one line at top of function that prints out time automatically when function returns) and put some in the popup and component classes… here’s the output for the showsubmenu call for submenu with two items:
…unfortunately I’m not familiar enough with the code to recognize if there’s much redundancy here… it’s not clear to me why toFront should be called so often… but I can live without the shadows for now.
Thanks for 1.46 btw I’ve been using the trunk anyway, but nice to know it’s been through your testing now.