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

[Pekka Paalanen]

On Mon, 25 Feb 2013 18:37:05 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> I think that has to be a bug in toytoolkit. It is actually drawing the 
> frame and buttons in different places. I don't think that is a 
> compositor or wayland api problem.

Yes, I think so, too.

> However more searching and I think you are right, the compositor thinks 
> the first thing it will get after a maximize configure is the maximized 
> window. This is simply going to be wrong sometimes because the client no 
> matter how careful, may manage to send a small buffer before it sees the 
> configure. The client has to send something that says "I now know my 
> window is maximized and will draw that way" which is batched with other 
> changes by the commit.

No, it really is an application bug. Below I explain how that can be
worked out. Careful synchronization is required indeed. In addition to
your concers, the compositor may have decided already to send a
configure event for other reasons, before it processes the maximization
request, so simply using "the first configure event after the maximize
request from the client's point of view" is also racy.

What we cannot have is the compositor deciding to ignore a frame based
on some heuristic of "not the expected size". We have valid cases, where
the client can send a frame with unexpected size, or even at the same
size as before.

> MoD wrote:
> > 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.

From the top of my head, the maximizing and fullscreening sequences
should go like this:

1. client decides it wants to maximize

2. client stops rendering any new frames

3. client sends wl_shell_surface.set_maximized request

4. client sends wl_display.sync request, and so creates a callback
object

5. client will wait, processing all incoming events, and storing the
values from the last wl_shell_surface.configure event received. No
rendering.

6. when the callback object gets acked, the client knows it has now
seen the configure event corresponding to the maximization request.

7. client resumes rendering, and uses the latest requested size, as
always

So yes, the client will have to stop until the roundtrip for
maximization has been completed.

If any of my explanation seems contradictory to the protocol spec, let
me know, please. I didn't verify it.


Thanks,
pq