It seems there is also an issue with the double buffered flow, namely to make it work cleanly in a the case of a surface spanning several outputs, those of course not in sync and with different refresh rates. Better not be in a hurry to do a "page flip" on a surface which covers several outputs.
On Thu, Mar 14, 2013 at 06:01:10PM +0100, John Kåre Alsaker wrote: ... > Anyway I do prefer the one workspace per output approach where you > can't see these race issues at all :) I do agree, then: The idea of a discret 2D dynamic matrix of stacks of outputs instead of a continous compositor space is, in my opinon, a model closer to what we would "see" in the reality. I picture a 2D matrix with slots. Pointer navigation over this matrix of slots should be quite straight forward. Clone use case: in a slot you would have a stack of outputs, but one master and all the others degraded clones, namely scaled copies of the master. The clients would only care of rendering in the master output of a slot. The compositor would take in charge the copy/scaling of the master to the clones since the compositor would be granted scaling powers in that case. Then clones do not exist for the clients. As we agreed before and for what was said about that matter, a surface would belong to and be rendered on one output only (master of a slot in the 2D matrix). The pointer navigation would need a "motion" that would be enhanced with the slot information since we aren't anymore in a continuous compositor space. Additionnaly, a client should be able to target a specific slot/master output for surface creation, or let a compositor policy decides the slot/master output then be told about it. The shell part/decorations of the surface should be able to detect a drag which crosses a slot/master output boundary and then should do the "jump" to the new slot/master output, if it wants to. All that means a massive refurbishment of the protocol in many areas. A last note on fullscreen scaling. Scaling, in that case, targets master output/slot which should not be handed to the compositor and rendered only by the clients (using hardware or not). Thanks. -- Sylvain _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
