<div dir="ltr"><div><div>I agree that the problems the poster is having is due to not sending damage requests, but I am not really certain the description of the requirement to send damage is correct.<br><br></div>I am pretty certain the plan for buffer_damage is to indicate the area that would have to be uploaded to the graphics card to update the texture map. The fact that if there is no change to the buffer->screen transform this also can be turned into a minimum screen area that has to be recomposited is a nice side-effect. If the transform *does* change, it would still be nice if the buffer_damage represented this texture upload area (in the unlikely scenario that the client reuses part of the old image for the new transform). Therefore potentially the buffer damage may be smaller than the area that needs to be recomposited on-screen.<br><br></div><div>It sounds like you are saying that on any transform change, the client must also send wl_surface.damage requests. But this then gets a little ambiguous. The actual on-screen area damaged is the union of both the old and new area of the surface. Yet all clients are only sending the new area of the surface. So either all clients are broken, or the compositor is detecting that the transform changed and using that to create more damage than the client requested.<br><br></div><div>I think perhaps the correct documentation is this:<br><br></div><div>wl_surface.buffer_damage:<br><br></div><div>Indicates what pixels in this buffer are different from the pixels in the previous buffer attached to the surface. The most direct use of this information is to limit the area that needs to be uploaded to a GPU texture to only the changed rectangle. However if no wl_surface.damage request is sent this area is transformed to screen space and used for that as well.<br><br></div><div>wl_surface.damage:<br><br></div><div>Indicates the area on-screen that must be redrawn to show the result of the commit. If this request is not sent, the area of wl_surface.buffer_damage 
is instead transformed to the screen and used. This will only work 
correctly if the transform does not change.<br></div><div><br></div><div>If the transform or buffer size changes, the compositor will always re-composite the on-screen area that was occupied by the old version of the surface but is *not* occupied by the new version. But it may limit re-compositing of the new area to only the area of the wl_surface.damage request. This will allow a client that happens to know that an area has not actually changed to indicate it does not need re-compositing (an actual example would be a client changing the buffer scale but drawing the same image at the new scale).<br><br></div><div>Most clients should send a wl_buffer.damage for the entire new area of the surface on any transformation change to make sure the screen is updated correctly. A client could equivalently send a buffer_damage request for the entire area of the new buffer.<br><br></div><div>Note that a lot of compositors are going to update the screen on some or all transformation changes even without the wl_surface.damage request. Clients should not rely on this.<br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 5:16 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">On Mon, 14 Dec 2015 13:00:06 +0000<br>
<span class="">Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> wrote:<br>
<br>
> On 14 December 2015 at 12:49, Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> wrote:<br>
> > On 14 December 2015 at 11:40, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br>
> >> On Tue, 08 Dec 2015 14:48:01 +0100<br>
> >> Matthias Treydte <<a href="mailto:mt@waldheinz.de">mt@waldheinz.de</a>> wrote:<br>
> >>> Either way, using the scaler API causes either too much drawing when<br>
> >>> used without setting the damage region (variant (b) above then should<br>
> >>> change nothing on screen at all, right?) -- or it causes insufficient<br>
> >>> drawing for variants (a) and (c) above.<br>
> >><br>
> >> We easily err on too much repainting, as it is safe. The damage region<br>
> >> handling is one of the most complicated pieces of Weston, and<br>
> >> optimizing it is hard. It also has some known inefficiencies, but yours<br>
> >> is a new observation, IIRC.<br>
> ><br>
> > Is it actually new, or is it just yet another occurrence of<br>
> > <a href="https://phabricator.freedesktop.org/T17" rel="noreferrer" target="_blank">https://phabricator.freedesktop.org/T17</a> ... ?<br>
><br>
> By which I obviously mean <a href="https://phabricator.freedesktop.org/T18" rel="noreferrer" target="_blank">https://phabricator.freedesktop.org/T18</a><br>
<br>
</span>I think it's a different issue. But yes, pointing out T18 was in my<br>
mind, just lazy to look it up. :-)<br>
<br>
T18 is about window management causing unnecessary GL texture uploads,<br>
while here we are looking at excessive repaints. So T18 is about<br>
weston_surface_damage doing the wrong thing, while the issue here would<br>
be akin to calling weston_surface_damage at inappropriate times in the<br>
first place.<br>
<br>
Because of T18, moving a window might sometimes "fix" a missing damage<br>
from the client.<br>
<br>
<br>
Thanks,<br>
pq<br>
<br>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br></blockquote></div><br></div>