[PATCH 2/2] protocol: Support scaled outputs and surfaces

[John Kåre Alsaker]

On Tue, May 21, 2013 at 5:35 PM, Bill Spitzak <spitzak at gmail.com> wrote:
 >However both proposals have this problem if pre-compositing is not done,
and most practical shells I can figure out can't do pre-compositing because
that requires another buffer for every parent, so maybe this is not a big
deal.
Pre-compositing or compositing of individual windows into buffers will be
required to be done for transparent subsurfaces which overlaps another
subsurface if the compositor wants to change the opacity of the window (a
common effect).

On Mon, May 20, 2013 at 11:23 AM, Pekka Paalanen <ppaalanen at gmail.com>wrote:

> Actually, it means that the surface coordinate system can change
> dramatically when a client sends a new buffer with a different scale,
> which then raises a bucketful of races: is an incoming event using new
> or old surface coordinates? That includes at least all input events
> with a surface position, and the shell geometry event.

This is not a new race. Resizing and surface content changing have the same
problem. Changing the scaling factor would be a relatively rare event too.
I believe I was told that the frame callback was usable as a separator of
events for frames. That could allow clients which are changing scaling
factors to translate old input correctly or simply ignore it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130521/fb752827/attachment.html>