Opened 10 years ago

Last modified 17 months ago

#5468 new bug

Draw() can overtake FrameResized()

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

Description

hrev35591

After resizing a view Draw() can be invoked with the new view bounds in effect (and a respective update rect) before the view's FrameResized() has been called.

This led to #2851, which has been fixed in hrev35587 by no longer relying on FrameResized() to be called before Draw().

As a simple test case the Terminal can be used. Insert the following at the beginning of Draw():

{
	int32 columns = (Bounds().IntegerWidth() + 1) / fFontWidth;
	int32 rows = (Bounds().IntegerHeight() + 1) / fFontHeight;
	if (columns != fColumns || rows != fRows)
		debugger("Draw(): view size changed without FrameResized()");
}

The debugger() call is triggered easily when resizing the Terminal window. Resizing in individual steps doesn't trigger it.

Change History (3)

comment:1 by axeld, 3 years ago

The view bounds are updated synchronously, while FrameResized() (and Draw()) are called asynchronously via messages. The app_server can issue a drawing update at any time, so the behavior is actually to be expected.

Of course, it would be possible to change the implementation in a way that FrameResized() is always called before Draw(). I'm just not sure if it's worth the hassle. Opinions welcome. In any case, if the current behavior is not changed, it should at least be documented.

comment:2 by jscipione, 17 months ago

Relevant commits list log: https://www.freelists.org/post/haiku-commits/haiku-hrev45852-in-src-appsdeskcalc-kitsshared,1

Test program is here: http://pastebin.com/hb3fne5V

The view starts off green. When you resize the view turns red. keep resizing and eventually it will turn blue, this means you've triggered the bug. more details below:

App server occasionally drops the Draw() call which causes the view to not be drawn correctly. Actually this happens on BeOS too but much more frequently on Haiku. I'm not sure if this is intentional or not and I'm not sure how to trigger the bug, it just seems to happen at random. It's not like if I resize the window quickly it happens more often, it just occasionally doesn't call Draw() and suddenly my red window turns blue.

Last edited 17 months ago by jscipione (previous) (diff)

comment:3 by jscipione, 17 months ago

After running the program linked in last comment on a more recent Haiku things have improved since 2013 (5 years ago today). Messages do not get dropped and we consistently call FrameResized() then Draw() however, the bug is still every bit as present and not even hard to trigger.

Note: See TracTickets for help on using tickets.