Opened 7 years ago

Last modified 2 years ago

#8895 assigned bug

Artifacts in menu bar when resizing horizontally

Reported by: humdinger Owned by: stippi
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #13067
Has a Patch: no Platform: All


This is hrev44534.

Resizing a Web+ window horizontally leave redrawing artifacts:

redrawing artifacts

Attachments (1)

web+_redrawing.png (6.5 KB) - added by humdinger 7 years ago.
redrawing artifacts

Download all attachments as: .zip

Change History (8)

Changed 7 years ago by humdinger

Attachment: web+_redrawing.png added

redrawing artifacts

comment:1 Changed 7 years ago by diver

Looks like a dupe of #8525.

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

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

comment:4 Changed 5 years ago by pulkomandy

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

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.

Last edited 5 years ago by pulkomandy (previous) (diff)

comment:5 Changed 5 years ago by pulkomandy

Component: Applications/WebPositiveKits/Interface Kit
Owner: changed from pulkomandy to stippi
Status: in-progressassigned

comment:6 Changed 2 years ago by humdinger

Blocking: 13067 added

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

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

Note: See TracTickets for help on using tickets.