Inconsistency with scaler extension?

[Pekka Paalanen]

On Tue, 08 Dec 2015 14:48:01 +0100
Matthias Treydte <mt at waldheinz.de> wrote:

> Hello,
> 
> while playing around with the scaler extension on Weston 1.9 I've 
> encountered some strange behavior I'd like to get some definitive input 
> for:
> 
> I'm using Weston 1.9 under X11 with the NVidia drivers, in case that 
> matters. My program does the following:
> 
>    1) have a surface (SA) which is made visible using the fullscreen 
> shell
>    2) have another surface (SB) which is made a sub-surface of (SA)
>    3) attach some shm buffer to (SB)
>    4) grab a viewport (VB) for (SB) using the scaler extension
>    5) set a destination on (VB) (which essentially scales the buffer a 
> tad)
> 
> There's also a frame callback on (SA) which animates the source property 
> of (VB):
> 
>    cb1) set some source area on (VB), animated using a timestamp
>    cb2) set an appropriate damage region on (SB)
>    cb3) commit (SB)
>    cb4) commit (SA)
> 
> Using this configuration, the output is as expected. But variations of 

Hi,

sounds about right.

> this do things I don't really understand:
> 
>    a) Omitting step (cb2) causes only the first call to (cb1) to have an 
> effect, the subsequent calls do not alter the output on screen

Not unexpected. It is your responsibility to mark areas damaged when
you change things. If you change viewport source rectangle, you
probably want to mark the whole surface as damaged.

>    b) Omitting (5) in the initialization phase *and* removing (cb2) 
> "repairs" this, cropping the buffer without scaling.

It's a side-effect you must not rely on. Compositors are free to
repaint also areas not marked as damaged.

>    c) Omitting (5) and (cb2) and replacing (cb1) with the viewport call 
> with the "set" call taking source and target parameters shows the same 
> behaviour as (a)

See the reply to a).

> So basically I'm not sure if manipulating viewport parameters implicitly 
> updates the damage region, or if the user has to do this himself.

Nothing implicitly updates the damage region.

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

> The documentation of the scaler API does not mention the need to call 
> "damage" at all, and the documentation for surface only mentions 
> attaching new buffers as a reason to call damage. I think some 
> clarification is needed here.

Right. Any operation a client does that would change the surface
appearance from its contents (wl_buffer contents and how it maps to the
surface) must be accompanied with the proper damage regions, or the
screen might not update correctly.

It's a bit hard to express in short. If the client does window
management requests, it is not expected to post damage only for those.
Content changes to the surface require posting damage, and content can
change by not just attaching another wl_buffer but also by changing how
the wl_buffer maps to the surface.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151214/a2bcd14c/attachment.sig>