[Interface Kit] menu frame draws a split second earlier than the contents draw

[diver]

From the comment:ticket:484:25

when browsing the file system with the context menu on the Desktop one may see the menu draw a split second earlier than the contents draw. Also when I click on the Desktop and all the submenus are closed I can sometimes see a menu without contents.

This is bad because it makes a bad impression on users that Haiku is slow and unresponsive.

[diver]

It seems it became much more visible in recent revisions. If you navigate to Deskbar->Application menu it will show an empty menu and a half second later it will be filled by menu items. If you close Deskbar menu and go there again you should see the same behavior. Shouldn't there be some kind of cache to prevent it?

Tested with hrev36568 in VirtualBox 3.0.12.

[stippi]

It could be related to localization. On real hardware, it's not possible to notice any kind of delay.

[jonas.kirilla]

It may be related to what can be seen when running the Live CD, where it's very visible, at least in Deskbar. E.g. when opening Deskbar's apps menu the first time, the menu opens with the right proportions but entirely grey. When you move the mouse pointer over it while still grey, the pointer tears "real drawing" (invalidates a series of squares as it moves?) revealing menu item text and icons, which for some reason are not shown yet. (This is on a unicore.)

[jackburton]

This is caused by the way Deskbar (and Tracker) draws their menus. They are, as now, the only menus in Haiku which make use of the "dynamic menu" api. I guess that we should change something in there (check BMenu::AttachedToWindow()).

[jackburton]

I found that applying the following patch fixes the problem, without causing any other issues.

[jackburton]

Replying to jackburton:

I found that applying the following patch fixes the problem, without causing any other issues.

Actually not. It just happened not to show up once or twice. But the problem is still there.

[leavengood]

Should be fixed in hrev44458.

[augiedoggie]

I'm not sure if this is fixed. It appears to me as though menu drawing is much worse now. I can see the outline of the rect drawn way before the background color is filled in(particularly when using virtualbox).

[leavengood]

Well the outline followed by the contents is definitely related to hrev44458, but beyond that, even BeOS rendered the menu background before the content (I was testing menus in BeOS within VirtualBox last weekend.) Probably marking this fixed based on hrev44458 was premature, but diver seemed to be happy with it which is why I closed it.

If we never want menus to show with partial content we would need to change how the window is shown, and I'm not even sure if it is possible to wait to show the window until the contents are drawn (well anything is possible, but I'm not sure how hacky it might be.)

Overall with all these issues related to Haiku being slow in VirtualBox, I think we have something about Haiku which VirtualBox does not like which makes it run slower than other OSes. I can recall years ago a VirtualBox developer scoffing about something being bad in Haiku, at least where VirtualBox was concerned. It might be worth looking at that more closely too. Though that doesn't mean we should ignore these issues which show up on slower machines.

[augiedoggie]

I wasn't really referring to the all of the menu contents. Just that, in my opinion, it looks worse to have the border drawn without the background color filled in. Perhaps I just didn't pay as much attention to it until I saw this ticket.

I forgot to add that this wasn't exclusive to virtualbox, just a bit more noticeable there. I can also see it on when running bare metal(PhenomII X4 with 8GB of ddr3)

[leavengood]

Well maybe making the menu background transparent was not a good idea. It just seems stupid having a view color because the menu draws its own background, so we are just letting the app_server draw a background which immediately gets drawn over. And that was what was causing the flickering in menu bars and to some extent menus (though in my testing it was much worse in the menu bar.)

Though with all this I have to wonder why there is flickering at all because I thought Stephan made all app_server drawing double buffered. Maybe the issue here is the app_server draws the default view color background, and then the client side drawing happens, and those two sets of drawing operations are not double buffered together, but each is separately double buffered.

[stippi]

This explanation makes sense.

[X512]

Replying to leavengood:

Well maybe making the menu background transparent was not a good idea. It just seems stupid having a view color because the menu draws its own background, so we are just letting the app_server draw a background which immediately gets drawn over. And that was what was causing the flickering in menu bars and to some extent menus (though in my testing it was much worse in the menu bar.)

Mayble problem actually happens because background color and bitmap are drawn by app_server and BView contents are drawn by application. It happens asynchronously. When app_server validates view it draw background and send validation request to an application. As result background is drawn even if application is hang.

[axeld]

IIRC the reason is simply that the menu is using a bordered window which is drawn directly by the app server, and the rest of the menu is now drawn from the client. While it would be nice to find out why the delay is so large that it is noticeable, it could easily be fixed by letting the menu draw its border itself as well.

[Giova84]

This bug is still present in hrev1alpha4-44674

[Giova84]

hrev45586 At least for me, now, this issue is no longer present. edit: and was present with revisions older than hrev45586

[Giova84]

Ops.. Sorry. If i open, in the Be Menu, a disk or a folder which contains hundreds of files and folder i can see the same behaviour as before. The fact is that the issue no longer happens with folders with few elements.

[diver]

Still here in hrev53129.

[X512]

This is like a problem in libtracker, not in interface kit. Tracker should not show menu until contents are ready. Tracker should not issue IO after menu is opened but contents are not ready.