Hi again, I put some more thoughts in those issues.
A client knows on which outputs its surfaces span over. Then the client is in charge of configuring its rendering to find the best trade off, but with one buffer. If the surface was entered on 2 outputs with really different DPIs... well it should configure its rendering based on the average of output DPIs? The user would move/resize the surface on one output if he wants to get a GUI rendered properly again. For the double buffered flow and very long page flips that could be induced for a surface spanning over several outputs... well too bad for the surface and the client. Regarding a discret vs continuous compositor space. If we accept the previous tradeoffs, a dynamic continuous compositor space is fine. But I'm still kind of uncomfortable to hand over to the compositor scaling in the case of fullscreen and buffer transform in the case of output tilting (renaming transform to tilting would not be a bad idea). Another though which targets sub-surface interfaces: are the hardware overlays for YUV buffers that more energy efficient than GPU scaling/color space conversion since most the energy would be burned into the video decoding anyway? thanks. -- Sylvain _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel