<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 11:47 PM, 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"><span class="">On Mon, 9 Nov 2015 10:28:13 -0800<br>
Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br>
<br>
> I believe wl_surface.damage should be defined as "the same as<br>
> w_surface.buffer_damage if the only transforms are due to an integer buffer<br>
> scale and the 8 possible buffer transforms". This means it is undefined if<br>
> the wl_scalar proposal is used, and avoids the need to define it for any<br>
> future transform possibilities.<br>
<br>
</span>I have no idea how that could help with anything. It does not matter<br>
what the mapping is between surface and buffer coordinate systems:<br>
damage is in surface space, and buffer_damage is in buffer space. There<br>
is nothing ambiguous about that, even if someone added even more<br>
transformations between them.<br></blockquote><div><br></div><div>A rectangle in a rotated coordinate space, or which has edges or corners that do not correspond to pixel edges/corners is ambiguous as far as describing what pixels are damaged. I suppose you could say that it is enlarged to the bounding box in buffer space but I think it might be better to just say that you should not use the old api.<br></div><br></div></div></div>