Inconsistency with scaler extension?

[Matthias Treydte]

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 
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
   b) Omitting (5) in the initialization phase *and* removing (cb2) 
"repairs" this, cropping the buffer without scaling.
   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)

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

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.

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.


Kind regards,
-Matthias Treydte