Artifacts in menu bar when resizing horizontally

[humdinger]

This is hrev44534.

Resizing a Web+ window horizontally leave redrawing artifacts:

[humdinger]

redrawing artifacts

[diver]

Looks like a dupe of #8525.

[leavengood]

I looked into this and it is definitely specific to the WebPositive menu bar. When being resized, the "updateRect" which is passed in BMenuBar::Draw can sometimes skip sections, meaning they are never filled in. The main thing which is different about WebPositive's menu bar is that it is within a horizontal layout group. I started trying to remove the menu bar from the layout group to definitely determine if that was the problem, but my quick hack changes just crashed Web+. I'll need to take a more deliberate approach, maybe even to add another application's menu bar to a layout and see if it has the same issues.

I'll look more into this later, but I suspect the layout code is making the resizing slower, and causing the skipping.

I will say that the only way I could reproduce the really bad artifacts like in the screenshot was to make VirtualBox really slow. But I could still see occasional single pixel lines at normal speed.

[humdinger]

FYI, I'm running Haiku natively on a notebook, Core2duo, 2ghz with a nVidia7600Go using the nvidia driver. Maybe not the fastest machine anymore, but should have plenty of oomph to redraw some windows properly. :)

[pulkomandy]

It's easy to reproduce if you have a page that's slow to redraw. Trac "query results" with its big array does well for that.

I tried removing the horizontal layout (and fullscreen button), but that doesn't seem to help much. I can still reproduce the issue with enough tabs open.

[humdinger]

(In #13067) Indeed, it's #8895. Reported by me and assigned to you. :)

[axeld]

I looked into the issue briefly, and I'm almost confident that it doesn't have (anymore, after hrev51035) anything to do with BView::FrameResized(); the Draw() calls match up.

Some interesting notes:

• In the non-layout constructor, a B_FULL_UPDATE_ON_RESIZE is being used. Adding this flag to the layout-supporting constructor let the problem go away.
• However, using Invalidate() in FrameResized() only works for the top most menu bar, not for the bookmark bar. This one left me clueless, to be honest.
• The white rectangles are most interesting. Since the app_server is responsible for invalidating newly exposed regions, this should not really happen.
• So, as a first hint, I'd look into the clipping regions used -- maybe they mess up the resizing in some way.

In general WebPositive only seems to relayout (showing Haiku's Trac) when shrinking the window, not when enlarging it (since it draws the page correctly after scrolling, it's more likely an update than a layout issue, though).

[X512]

Fixed by ​https://review.haiku-os.org/c/haiku/+/2099.

[diver]

Fixed in hrev53706. Thanks!

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone