<div dir="ltr">On Tue, May 21, 2013 at 5:35 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br><div> >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.</div>
<div>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).</div>
<div><br><div class="gmail_quote">On Mon, May 20, 2013 at 11:23 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Actually, it means that the surface coordinate system can change<br></div>
dramatically when a client sends a new buffer with a different scale,<br>
which then raises a bucketful of races: is an incoming event using new<br>
or old surface coordinates? That includes at least all input events<br>
with a surface position, and the shell geometry event.</blockquote><div>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.</div>
</div></div></div>