wl_subsurace position - double buffered state?

[Scott Anderson]

On 30/10/19 10:41 am, Martin Stransky wrote:
> Hi Guys,
> 
> while solving a FF bug [1] I'm unable to figure out why a subsurface has 
> wrong offset. There's the related part of wayland-debug log:
> 
> [1622539.791]  -> wl_compositor at 53.create_surface(new id wl_surface at 61)
> 
> [1622539.821]  -> wl_subcompositor at 57.get_subsurface(new id 
> wl_subsurface at 62, wl_surface at 61, wl_surface at 42)
> 
> gdk_window_get_position 26 23
> 
> [1622539.857]  -> wl_subsurface at 62.set_position(26, 23)
> 
> [1622539.868]  -> wl_subsurface at 62.set_desync()
> 
> [1622539.874]  -> wl_compositor at 53.create_region(new id wl_region at 63)
> 
> [1622539.882]  -> wl_surface at 61.set_input_region(wl_region at 63)
> 
> [1622539.889]  -> wl_region at 63.destroy()
> 
> [1622539.904]  -> wl_surface at 61.set_buffer_scale(2)
> 
> [1622539.912]  -> wl_surface at 61.commit()
> 
> 
> but I still see the sub surface on old initial position (0,0). It's 
> moved to correct position imediately when I try to resize the window. 
> (full log is attached).
> 
> Sometimes it happens that the surface is on correct position right after 
> start - but I don't see any difference in the log.
> 
> It's on Fedora 30 / mutter-3.32.2-4.fc30.x86_64.
> 
> Any idea what can be wrong?
> 
> Thanks,
> Martin
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1592350

Hi Martin.

The wl_subsurface position is actually a property of the parent surface, 
and will be applied on wl_surface.commit for the parent. It's that way 
so you can set the position of several subsurfaces and have them all be 
applied atomically.

Scott