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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
