mirror of
https://gitlab.freedesktop.org/wayland/weston
synced 2024-07-21 10:44:25 +00:00
ad0da4596d
Normal windows enter the MapRequest handler, which schedules drawing the decorations. Then Xwayland realizes the window, which ends with a call to xserver_map_shell_surface(). The decorations are already drawn, no need to draw them a second time. However, MapRequest handler could not set the pending state because the weston_surface did not exist at the time, because it gets created only when Xwayland realizes the window, which happens after XWM has forwarded the MapWindow in MapRequest handler. Therefore set the pending state explicitly at the end. Scheduling had it done much later anyway. Now that the pending state is set much earlier, it seems to be more likely that it gets set before Xwayland's first commit is handled. This means that -geometry command line option of X11 apps already takes the geometry (decorations) into account. I do not think it is reliable yet, though. There is still the race between Xwayland committing and XWM setting the pending state assuming the very next commit latches it in appropriately. The race exists not because of Wayland, but because WL_SURFACE_ID comes via X11, and could be processed after wl_compositor.create_surface and wl_surface.commit. That commit/pending race is solved by a following patch. For override-redirect windows weston_wm_window_schedule_repaint() reduced into a call to weston_wm_window_set_pending_state_OR(), so we can just call that directly. It should not matter that the call is moved to the end of the function. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Acked-by: Daniel Stone <daniels@collabora.com> |
||
|---|---|---|
| .. | ||
| dnd.c | ||
| hash.c | ||
| hash.h | ||
| launcher.c | ||
| selection.c | ||
| window-manager.c | ||
| xwayland-api.h | ||
| xwayland-internal-interface.h | ||
| xwayland.h | ||