Re: Weston screenshooter blocks the display for over a second

2019-10-30 Thread The Rasterman
On Mon, 28 Oct 2019 18:43:02 +0100 CHUCO POGA  said:

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

If the screen is freezing entirely then it's not the client that is at fault
but the compositor, so you want to be debugging the compositor code (weston)
not the client. The client may help illustrate which requests are being sent at
that time, but it's the compositor at fault here.

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wl_subsurace position - double buffered state?

2019-10-30 Thread Jonas Ã…dahl
On Tue, Oct 29, 2019 at 10:41:08PM +0100, 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?

Hi,

Quoting the specification of the set_position request:

The scheduled coordinates will take effect whenever the state of the
parent surface is applied. When this happens depends on whether the
parent surface is in synchronized mode or not. See
wl_subsurface.set_sync and wl_subsurface.set_desync for details.

In short, you need to commit the parent surface for the new position to
take effect. The reason for this is that the position of the surface is
more of a state of the parent surface rather than the subsurface itself,
and it is likely that if you move the subsurface, something on the
parent surface needs to be updated at the same time in order to avoid
intermediate incorrectly rendered frames.


Jonas


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