[Interface Kit] resizing some windows leaves artifacts

[aldeck]

might be that's what's hapenning in #1849. there might be other similar tickets to find...

[diver]

Seems to be fixed, see bug #3574.

[stippi]

Ok, thanks for the feedback!

[diver]

I just have the time to actually test it, and this bug is still here. Reopening...

[aldeck]

Happens quite reliably here with DeskCalc under vmware. Not too sure, but it seems it helps (to reproduce) when artificially slowing down the drawing.

[diver]

Still here in hrev35572.

[diver]

Still reproducible in VirtualBox with hrev38300.

[ttcoder]

Will probably weight on this ticket in the future as it occurs in TunePrepper, an app which relies heavily on class BBox and B_FOLLOW_LEFT_RIGHT (seemingly like in the above screen grab attachment:filetypes.png​ from diver).

[ttcoder]

I took a look at the BBox.cpp history log and I have a W.A.G.:

Could it be that hrev29574 (the fix to #3574) was broken/regression by hrev30189 ?

[AGMS]

BBoxes leave artifacts as they are resized, in my case it was making the box wider by dragging the window resize wider with a BBox that follows-right (it's also an old style non-layout box). The trouble seems to be in BBox::FrameResized having an off by one error in the invalidation of the lines of the box (possibly due to the screwy BeOS coordinate system where Width isn't pixel width). Artifacts are visible for both plain and fancy border styles (none with no border). My temporary fix is to subclass FrameResized and do an Invalidate() to redraw the whole view.

[axeld]

Is there an application on the default image (or in HaikuDepot) that easily allows to reproduce the issue?

[AGMS]

No example programs (at least in all the preferences), I think they all use the Layout system and somehow redraw differently. I'll write up an example program, and try making a patch too if I can recreate it. It could be something like a child BView inside the BBox not updating or being transparent in Haiku but solid colour in BeOS.

[AGMS]

The trouble is that your computer is too fast! When loaded down with lots of child BViews, the resizing can skip a pixel or more and the invalidation misses some of the old box lines. I've made up an example that slows things down (see attached .cpp file with a FrameResized speed bump) and it's easy to get the glitches to happen when resizing the window.

[AGMS]

Program for recreating the graphics glitch, by slowing down FrameResized().

[axeld]

Fixed in hrev51035. The main problem was actually outside of BBox.

[AGMS]

Whew, what an obscure fix, I wouldn't have found that without spending lots of time on it. Thanks.

[axeld]

Your test app was a great help, thanks!

[Janus]

I can still reproduce the problem in hrev51702 (VirtualBox).

[Janus]

The problem is present when there is a BTextControl and a method that modifies the inner BTextView is invoke in the example the BTextControl is disabled.

[stippi]

Interesting observation. If memory serves, BTextView does something weird when asked for its minimum size. It does text layouting only from within Draw(). And when it needs to know its minimum height for a given width, it only knows that after actually drawing the text at the given width which is not (yet) actually the current width of the control nor may it ever be. This is bad, since it modifies the layout when this method should be "read-only" (except for maybe updating some layout caching variables). Drawing outside of an actual Draw() hook call while there are indeed pending updates may also interfere with the update-cycle.

BTW, this situation was one of the main motivations for starting my own text view framework in HaikuDepot. But that one is not yet complete enough to be an alternative.

[diver]

Can't seem to reproduce anymore.

[AGMS]

My usual BeShare resizing test works perfectly now; hrev53701. Maybe a bit more flickering as borders get redrawn more agressively, but the end result is good.

[X512]

Issue should be fixed in hrev53706.

[diver]

Likely fixed in hrev53706.

[nielx]

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