Opened 15 years ago

Last modified 19 months ago

#4335 assigned bug

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

Reported by: diver Owned by: X512
Priority: normal Milestone: R1.1
Component: Kits/Interface Kit/BMenu Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #8886
Platform: All

Description

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.

Change History (30)

comment:1 by diver, 15 years ago

Version: R1/pre-alpha1R1/Development

comment:2 by diver, 15 years ago

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.

comment:3 by stippi, 15 years ago

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

comment:4 by jonas.kirilla, 15 years ago

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.)

comment:5 by jackburton, 15 years ago

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()).

comment:6 by jackburton, 15 years ago

patch: 01

comment:8 by jackburton, 15 years ago

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

in reply to:  8 comment:9 by jackburton, 15 years ago

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.

comment:10 by nielx, 13 years ago

patch: 10

comment:11 by leavengood, 12 years ago

Owner: changed from axeld to leavengood
Status: newin-progress

comment:12 by leavengood, 12 years ago

Resolution: fixed
Status: in-progressclosed

Should be fixed in hrev44458.

comment:13 by augiedoggie, 12 years ago

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).

comment:14 by leavengood, 12 years ago

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.

comment:15 by augiedoggie, 12 years ago

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)

Last edited 12 years ago by augiedoggie (previous) (diff)

comment:16 by leavengood, 12 years ago

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.

comment:17 by stippi, 12 years ago

This explanation makes sense.

in reply to:  16 comment:18 by X512, 12 years ago

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.

comment:19 by diver, 12 years ago

Resolution: fixed
Status: closedreopened

comment:20 by diver, 12 years ago

Blocking: 8886 added

comment:21 by diver, 12 years ago

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

comment:22 by axeld, 12 years ago

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.

comment:23 by Giova84, 12 years ago

This bug is still present in hrev1alpha4-44674

comment:24 by Giova84, 12 years ago

hrev45586 At least for me, now, this issue is no longer present.

Version 0, edited 12 years ago by Giova84 (next)

comment:25 by Giova84, 12 years ago

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.

comment:26 by diver, 6 years ago

Still here in hrev53129.

comment:27 by diver, 5 years ago

Cc: X512 added

comment:28 by X512, 5 years ago

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.

comment:29 by diver, 5 years ago

Cc: X512 removed
Owner: changed from leavengood to X512
Status: reopenedassigned

comment:30 by pulkomandy, 4 years ago

Milestone: R1R1.1

comment:31 by pulkomandy, 19 months ago

Component: Kits/Interface KitKits/Interface Kit/BMenu
Note: See TracTickets for help on using tickets.