Inconsistency with scaler extension?

[Bill Spitzak]

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.

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.

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.

I think perhaps the correct documentation is this:

wl_surface.buffer_damage:

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.

wl_surface.damage:

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.

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).

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.

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.


On Mon, Dec 14, 2015 at 5:16 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Mon, 14 Dec 2015 13:00:06 +0000
> Daniel Stone <daniel at fooishbar.org> wrote:
>
> > On 14 December 2015 at 12:49, Daniel Stone <daniel at fooishbar.org> wrote:
> > > On 14 December 2015 at 11:40, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> > >> On Tue, 08 Dec 2015 14:48:01 +0100
> > >> Matthias Treydte <mt at waldheinz.de> wrote:
> > >>> Either way, using the scaler API causes either too much drawing when
> > >>> used without setting the damage region (variant (b) above then should
> > >>> change nothing on screen at all, right?) -- or it causes insufficient
> > >>> drawing for variants (a) and (c) above.
> > >>
> > >> We easily err on too much repainting, as it is safe. The damage region
> > >> handling is one of the most complicated pieces of Weston, and
> > >> optimizing it is hard. It also has some known inefficiencies, but
> yours
> > >> is a new observation, IIRC.
> > >
> > > Is it actually new, or is it just yet another occurrence of
> > > https://phabricator.freedesktop.org/T17 ... ?
> >
> > By which I obviously mean https://phabricator.freedesktop.org/T18
>
> I think it's a different issue. But yes, pointing out T18 was in my
> mind, just lazy to look it up. :-)
>
> T18 is about window management causing unnecessary GL texture uploads,
> while here we are looking at excessive repaints. So T18 is about
> weston_surface_damage doing the wrong thing, while the issue here would
> be akin to calling weston_surface_damage at inappropriate times in the
> first place.
>
> Because of T18, moving a window might sometimes "fix" a missing damage
> from the client.
>
>
> Thanks,
> pq
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151214/3a99428f/attachment-0001.html>