Opened 11 years ago

Last modified 21 months ago

#3037 reopened bug

[Interface Kit] resizing some windows leaves artifacts

Reported by: diver Owned by: axeld
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc: degea@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description


Attachments (4)

filetypes.png (91.2 KB ) - added by diver 11 years ago.
BBox Resizing Artifacts.png (17.6 KB ) - added by AGMS 2 years ago.
BBoxGraphicsGlitch.cpp (1.7 KB ) - added by AGMS 2 years ago.
Program for recreating the graphics glitch, by slowing down FrameResized().
GlitchBBox.gif (372.1 KB ) - added by Janus 21 months ago.

Download all attachments as: .zip

Change History (30)

by diver, 11 years ago

Attachment: filetypes.png added

comment:1 by diver, 11 years ago

Component: - GeneralKits/Interface Kit

comment:2 by aldeck, 11 years ago

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

comment:3 by diver, 11 years ago

Seems to be fixed, see bug #3574.

comment:4 by stippi, 11 years ago

Resolution: fixed
Status: newclosed

Ok, thanks for the feedback!

comment:5 by diver, 11 years ago

Resolution: fixed
Status: closedreopened

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

comment:6 by aldeck, 10 years ago

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

comment:7 by diver, 10 years ago

Version: R1/pre-alpha1R1/Development

comment:8 by diver, 10 years ago

Still here in hrev35572.

comment:9 by diver, 9 years ago

Still reproducible in VirtualBox with hrev38300.

comment:10 by ttcoder, 7 years ago

Cc: degea@… added

Will probably weight in 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).

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

comment:11 by ttcoder, 7 years ago

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 ?

comment:12 by AGMS, 2 years ago

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.

by AGMS, 2 years ago

Attachment: BBox Resizing Artifacts.png added

comment:13 by AGMS, 2 years ago

Has a Patch: set

comment:14 by AGMS, 2 years ago

Has a Patch: unset

comment:15 by axeld, 2 years ago

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

comment:16 by AGMS, 2 years ago

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.

comment:17 by AGMS, 2 years ago

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.

by AGMS, 2 years ago

Attachment: BBoxGraphicsGlitch.cpp added

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

comment:18 by AGMS, 2 years ago

Has a Patch: set

comment:19 by AGMS, 2 years ago

Has a Patch: unset

comment:20 by axeld, 2 years ago

Status: reopenedin-progress

comment:21 by axeld, 2 years ago

Resolution: fixed
Status: in-progressclosed

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

comment:22 by AGMS, 2 years ago

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

comment:23 by axeld, 2 years ago

Your test app was a great help, thanks!

by Janus, 21 months ago

Attachment: GlitchBBox.gif added

comment:25 by Janus, 21 months ago

Resolution: fixed
Status: closedreopened

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

comment:26 by Janus, 21 months ago

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.

comment:27 by stippi, 21 months ago

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.

Note: See TracTickets for help on using tickets.