I think (though certainly have not proven) that the current "commit"
mechanism will work for this. The client connects surfaces together into
a tree, and when a change is made to a surface the compositor does not
display the new version until a "commit" is done on either it or a
parent surface. In effect the "begin_atomic" is automatically done for
you, and "commit" is the "end_atomic".
There are currently attempts to use it to synchronize subsurfaces. IMHO
there is absolutely no difference between subsurfaces and floating
windows so I think any solution here will apply to the floating windows.
No matter what scheme is used, however, it does require that the client
decide whether to minimize a surface or not, so it can combine that
minimization with other changes into an atomic operation.
Jason Ekstrand wrote:
Bill,
The API must be designed so that no composite other than the initial and
final is ever produced, even for a split second, for each of these
transitions. By "other composite" I mean any different stacking order or any
where the set of visibility of surfaces is different.
I think this is a valid issue, but I'm not sure if we can really solve
it easily by building it into the max/min protocol.
You've brought this issue of synchronization up before on other
topics, so I think it's probably more general than simply maximizing
and minimizing. One thought would be to add some sort of "atomic"
support to the protocol. For instance, you could have "begin_atomic"
and "end_atomic" requests in wl_display that would tell the compositor
that whatever requests it receives between begin_atomic and end_atomic
should occur in a single frame. This would probably require some
additional support in libwayland to handle the threading issues
properly but I think it could probably be done. Obviously such a
thing would have to be used with extreme care and only short sequences
should be atomic.
To be honest, I haven't given that much thought. However if you
wanted to play with it and send a patch to the ML, I'd be more than
happy to take a look at it.
Thanks,
--Jason Ekstrand
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
