Opened 10 years ago

Last modified 6 years ago

#4335 reopened bug

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

Reported by: diver Owned by: leavengood
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #8886
Has a Patch: no 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 (24)

comment:1 Changed 9 years ago by diver

Version: R1/pre-alpha1R1/Development

comment:2 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by stippi

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

comment:4 Changed 9 years ago by 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.)

comment:5 Changed 9 years ago by 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()).

comment:6 Changed 9 years ago by jackburton

Has a Patch: set

comment:8 Changed 9 years ago by jackburton

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

comment:9 in reply to:  8 Changed 9 years ago by 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.

comment:10 Changed 7 years ago by nielx

Has a Patch: unset

comment:11 Changed 7 years ago by leavengood

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

comment:12 Changed 7 years ago by leavengood

Resolution: fixed
Status: in-progressclosed

Should be fixed in hrev44458.

comment:13 Changed 7 years ago by 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).

comment:14 Changed 7 years ago by 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.

comment:15 Changed 7 years ago by 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)

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

comment:16 Changed 7 years ago by 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.

comment:17 Changed 7 years ago by stippi

This explanation makes sense.

comment:18 in reply to:  16 Changed 7 years ago by 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.

comment:19 Changed 7 years ago by diver

Resolution: fixed
Status: closedreopened

comment:20 Changed 7 years ago by diver

Blocking: 8886 added

comment:21 Changed 7 years ago by diver

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 Changed 7 years ago by 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.

comment:23 Changed 6 years ago by Giova84

This bug is still present in hrev1alpha4-44674

comment:24 Changed 6 years ago by Giova84

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

Last edited 6 years ago by Giova84 (previous) (diff)

comment:25 Changed 6 years ago by 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.

Note: See TracTickets for help on using tickets.