[PATCH weston] toytoolkit: avoid redrawing a window between when it asks to be maximized and when it gets the configure

[MoD]

The bad frame looks like this: <http://i.imgur.com/qLO81SO.png>.
It does seem like a bad idea to simply drop intermittent frames when expecting
a maximize, but reading the protocol documentation ("The compositor will reply
with a configure event telling the expected new surface size.") it seems the
only indication of a maximization finishing is the configure. It seems like the
client should be able to simply respond to the configure as soon as it gets it
by displaying frames of the proper new size, but I was under the impression that
was what toytoolkit was doing already.

I guess I'm a bit confused as to what precisely is happening.

Bill Spitzak wrote:
>
>Though I can see this saving an unnecessary redraw of the small 
>window, 
>this really should not produce such a bad frame.
>
>If the client draws the "small" window then it will send a "small" 
>buffer size to the compositor. The compositor can tell that this 
>is not 
>the "large" window and therefore it can put it at the old position 
>(or 
>possibly ignore it, but that might be a problem).
>
>I can't seem to locate it now, but I thought the client actually 
>sent a 
>request saying it was now drawing the maximized window (as opposed 
>to 
>the request that it wants a configure event to get the size to 
>make the 
>maximized window). This would be much more reliable than just 
>having the 
>compositor look at window sizes.
>
>The only glitch should be that you may see the button un-press on 
>the 
>small window, then it change to the large window. If that is not 
>wanted 
>then toytoolkit should keep the button pressed down while waiting 
>for 
>the configure. This should be done by making the widget actually 
>draw in 
>a down position, not by blocking updates like this is doing. 
>Otherwise 
>animation in the window will stop until the maximize happens, 
>which 
>makes the software look a bit dated...
>
>MoD wrote:
>> This patch is intended to resolve a bad frame that is visible 
>when maximizing 
>> toytoolkit programs by clicking the maximize button in their 
>decorations. The
>> issue, as far as I can tell, is that toytoolkit queues a draw to 
>restore the
>> button to its unclicked state at the same time it asks for its 
>shell surface to
>> be maximized. It then ends up drawing a small window on a large, 
>maximized
>> surface in the top-left corner of the screen. This patch adds a 
>flag to the
>> window which indicates that a resize has been requested but not 
>received, and
>> avoids drawing until a configure is received.