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
