Draw() can overtake FrameResized()

[bonefish]

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.

[axeld]

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.

[jscipione]

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.

[jscipione]

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.

[waddlesplash]

Cc X512: Did your recent changes affect this, or is it still an issue?

[X512]

Should be fixed in hrev53706, need retest.

[X512]

Still present in hrev53987.

Issue is similar to https://dev.haiku-os.org/ticket/15619.

[X512]

Program to reproduce. "Size don't match" in stdout indicate bug.

[jscipione]

I'm afraid that this bug cannot be fixed without changing how messages work unfortunately. There's no way for us to guarantee that a Draw() call will happen after a FrameResized() call without implementing a transaction. Most of the time it works but without a guarantee that messages will arrive in a certain order there are race conditions that pop-up now and then. This is a design flaw and was as much a problem on BeOS as it is on Haiku fundamentally. I've also observed that sliders sometimes don't send the message (or the receiver never get it.) For example in Deskbar preferences when you click to change the slider value, occasionally the icons don't resize and we end up in an invalid state. This is not a fault of the Deskbar code but is a bug somewhere deeper in the messaging system. I'm not sure if that bug is related to this one or not.