Re: wl_subsurace position - double buffered state?

2019-10-29 Thread 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@53.create_surface(new id wl_surface@61)

[1622539.821]  -> wl_subcompositor@57.get_subsurface(new id 
wl_subsurface@62, wl_surface@61, wl_surface@42)


gdk_window_get_position 26 23

[1622539.857]  -> wl_subsurface@62.set_position(26, 23)

[1622539.868]  -> wl_subsurface@62.set_desync()

[1622539.874]  -> wl_compositor@53.create_region(new id wl_region@63)

[1622539.882]  -> wl_surface@61.set_input_region(wl_region@63)

[1622539.889]  -> wl_region@63.destroy()

[1622539.904]  -> wl_surface@61.set_buffer_scale(2)

[1622539.912]  -> wl_surface@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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

wl_subsurace position - double buffered state?

2019-10-29 Thread Martin Stransky 

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@53.create_surface(new id wl_surface@61)

[1622539.821]  -> wl_subcompositor@57.get_subsurface(new id 
wl_subsurface@62, wl_surface@61, wl_surface@42)


gdk_window_get_position 26 23

[1622539.857]  -> wl_subsurface@62.set_position(26, 23)

[1622539.868]  -> wl_subsurface@62.set_desync()

[1622539.874]  -> wl_compositor@53.create_region(new id wl_region@63)

[1622539.882]  -> wl_surface@61.set_input_region(wl_region@63)

[1622539.889]  -> wl_region@63.destroy()

[1622539.904]  -> wl_surface@61.set_buffer_scale(2)

[1622539.912]  -> wl_surface@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

--
Martin Stransky
Software Engineer / Red Hat, Inc
[1621949.941]  -> wl_display@1.get_registry(new id wl_registry@2)
[1621950.003]  -> wl_disp...@1.sync(new id wl_callback@3)
[1621950.163] wl_display@1.delete_id(3)
[1621950.182] wl_registry@2.global(1, "wl_drm", 2)
[1621950.206] wl_registry@2.global(2, "wl_compositor", 4)
[1621950.226]  -> wl_regis...@2.bind(2, "wl_compositor", 3, new id [unknown]@4)
[1621950.261] wl_registry@2.global(3, "wl_shm", 1)
[1621950.279]  -> wl_regis...@2.bind(3, "wl_shm", 1, new id [unknown]@5)
[1621950.403]  -> wl_shm@5.create_pool(new id wl_shm_pool@6, fd 12, 2304)
[1621950.638]  -> wl_shm_pool@6.resize(6912)
[1621950.793]  -> wl_shm_pool@6.resize(16128)
[1621951.043]  -> wl_shm_pool@6.resize(34560)
[1621951.524]  -> wl_shm_pool@6.resize(71424)
[1621954.076]  -> wl_shm_pool@6.resize(145152)
[1621954.198]  -> wl_shm_pool@6.resize(292608)
[1621955.727]  -> wl_shm_pool@6.resize(587520)
[1621959.196]  -> wl_shm_pool@6.resize(1177344)
[1621975.710] wl_registry@2.global(4, "wl_output", 2)
[1621975.733]  -> wl_regis...@2.bind(4, "wl_output", 2, new id [unknown]@7)
[1621975.796]  -> wl_disp...@1.sync(new id wl_callback@8)
[1621975.806] wl_registry@2.global(6, "zxdg_output_manager_v1", 1)
[1621975.817]  -> wl_regis...@2.bind(6, "zxdg_output_manager_v1", 1, new id 
[unknown]@9)
[1621975.831]  -> zxdg_output_manager_v1@9.get_xdg_output(new id 
zxdg_output_v1@10, wl_output@7)
[1621975.840]  -> wl_disp...@1.sync(new id wl_callback@11)
[1621975.847] wl_registry@2.global(7, "wl_data_device_manager", 3)
[1621975.859]  -> wl_regis...@2.bind(7, "wl_data_device_manager", 3, new id 
[unknown]@12)
[1621975.872] wl_registry@2.global(8, "gtk_primary_selection_device_manager", 1)
[1621975.882]  -> wl_regis...@2.bind(8, "gtk_primary_selection_device_manager", 
1, new id [unknown]@13)
[1621975.896] wl_registry@2.global(9, "wl_subcompositor", 1)
[1621975.906]  -> wl_regis...@2.bind(9, "wl_subcompositor", 1, new id 
[unknown]@14)
[1621975.920] wl_registry@2.global(10, "xdg_wm_base", 2)
[1621975.930] wl_registry@2.global(11, "zxdg_shell_v6", 1)
[1621975.939] wl_registry@2.global(12, "wl_shell", 1)
[1621975.949] wl_registry@2.global(13, "gtk_shell1", 3)
[1621975.959]  -> wl_regis...@2.bind(13, "gtk_shell1", 3, new id [unknown]@15)
[1621975.972] wl_registry@2.global(14, "wp_viewporter", 1)
[1621975.982] wl_registry@2.global(15, "zwp_pointer_gestures_v1", 1)
[1621975.991]  -> wl_regis...@2.bind(15, "zwp_pointer_gestures_v1", 1, new id 
[unknown]@16)
[1621976.005] wl_registry@2.global(16, "zwp_tablet_manager_v2", 1)
[1621976.014]  -> wl_regis...@2.bind(16, "zwp_tablet_manager_v2", 1, new id 
[unknown]@17)
[1621976.028] wl_registry@2.global(17, "wl_seat", 5)
[1621976.038]  -> wl_regis...@2.bind(17, "wl_seat", 5, new id [unknown]@18)
[1621978.926]  -> wl_compositor@4.create_surface(new id wl_surface@19)
[1621978.947]  -> gtk_primary_selection_device_manager@13.get_device(new id 
gtk_primary_selection_device@20, wl_seat@18)
[1621978.957]  -> wl_data_device_manager@12.get_data_device(new id 
wl_data_device@21, wl_seat@18)
[1621979.063]  -> wl_compositor@4.create_surface(new id wl_surface@22)
[1621979.072]  -> zwp_tablet_manager_v2@17.get_tablet_seat(new id 
zwp_tablet_seat_v2@23, wl_seat@18)
[1621979.082]  -> wl_disp...@1.sync(new id wl_callback@24)
[1621979.090] wl_registry@2.global(18, "zwp_relative_pointer_manager_v1", 1)
[1621979.101] wl_registry@2.global(19, "zwp_pointer_constraints_v1", 1)
[1621979.111] wl_registry@2.global(20, "zxdg_exporter_v1", 1)
[1621979.121]  -> wl_regis...@2.bind(20, "zxdg_exporter_v1", 1, new id 
[unknown]@25)
[1621979.135] wl_registry@2.global(21, "zxdg_importer_v1", 1)
[1621979.145]  -> wl_regis...@2.bind(21, "zxdg_importer_v1", 1, new id 
[unknown]@26)
[1621979.158] wl_registry@2.global(22, "zwp_linux_dmabuf_v1",

Re: Weston screenshooter blocks the display for over a second

2019-10-29 Thread Pekka Paalanen 
On Mon, 28 Oct 2019 18:43:02 +0100
CHUCO POGA  wrote:

> When attempting to make a screenshot under weston with Mod + S
> (weston-screenshooter), the entire display get's blocked for over a second.
> That causes an ugly jitter on the screen when displaying dynamic content
> (such as movies)
> 
> I have looked into the screenshooter client code and did some performance
> measurements, and it appears that the while(!buffer_copy_done) loop which
> calls wl_display_roundtrip takes a second to finish. Is there any way to
> make the screenshot async, to not interfere the currently displayed
> content? Or is it the way the protocol works under the hood?

Hi,

the while-loop you mention is in the screenshooter client, and I see it
is a busy-roundtrip which is not nice. Does putting a small delay in
that loop make things better? E.g. nanosleep().

If not, you will have to debug or profile the compositor instead to see
where the time is spent.

If yes, the client should be fixed to dispatch only instead of
roundtrip.


Thanks,
pq


pgpQLfJgtACJb.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Weston screenshooter blocks the display for over a second

2019-10-29 Thread CHUCO POGA 
When attempting to make a screenshot under weston with Mod + S
(weston-screenshooter), the entire display get's blocked for over a second.
That causes an ugly jitter on the screen when displaying dynamic content
(such as movies)

I have looked into the screenshooter client code and did some performance
measurements, and it appears that the while(!buffer_copy_done) loop which
calls wl_display_roundtrip takes a second to finish. Is there any way to
make the screenshot async, to not interfere the currently displayed
content? Or is it the way the protocol works under the hood?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel