[PATCH weston] toytoolkit: avoid redrawing a window between when it asks to be maximized and when it gets the configure
Bill Spitzak
spitzak at gmail.com
Mon Feb 25 18:37:05 PST 2013
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.
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.
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.
>
> I guess I'm a bit confused as to what precisely is happening.
More information about the wayland-devel
mailing list