[Wayland-bugs] [Bug 744932] Wrong (ultra tiny/small) cursor size on HiDPI screen

[mutter (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=744932

--- Comment #137 from Jonas Ådahl <jadahl at gmail.com> ---
(In reply to Owen Taylor from comment #133)
> Review of attachment 310989 [details] [review]:
> 
> I agree that this commit doesn't change behavior. The comment however, makes
> no sense to me - when I try to work out in detail why putting Xwayland
> windows through this code path prevens initial black flashes, I fail.
> 
> ::: src/wayland/meta-wayland-surface.c
> @@ +551,3 @@
> +       * complying with the frame callback specification is that XWayland
> will not
> +       * post any damage until after we map the surface actor, and we would
> +       * initially draw the inital content (usually black).
> 
> So, let's consider the case of an undecorated window - which is the simple
> case that in classic X apps can get right without any flashing. The app
> does, for example:
> 
>  Set window background to none 
>  MapWindow
>  draw to an offscreen pixmap
>  CopyArea to the window
> 
> This doesn't flash in the X composited case  because of "backfilling" - the
> newly allocated pixmap backing the window is filled in with a copy of that
> area of the root window, so it's "transparent". (The window's shadow might
> show up before it's contents, however.)  
> 
> [ Note: GTK+ 3 with the extended frame sync protocol and mutter gets this
> entirely right and waits for the app to be done before showing the window,
> instead of counting on backfilling - but we can assume that GTK+ 3 apps will
> be native Wayland ]
> 
> This sequence is inevitably prone to flashing on Xwayland because we can't
> do the backfilling and there is nothing in the X protocol to know when the
> app is "finished drawing"
> 
> So how does it matter whether we send frame callbacks:
> 
>  - After the window is drawn
>  - After the next frame after we receive the commit with the damage is drawn
> 
> I can't see how it would, since we *only* can receive these commits after
> the X server has attached a buffer - and at this point we should already
> have mapped and be drawing the window.

The initial few buffers (haven't counted) XWayland attaches are black (maybe
not GTK+ 3 X11 windows, they were not part of my test cases). Since XWayland
throttles buffer attaching using wl_surface_frame (it wont attach a new buffer
before receiving a frame callback), by waiting with replying with initial frame
callbacks until we have mapped, we will effectively stop XWayland from
attaching non-black buffers until we have already mapped and drawn the window
already.

The non-change is to continue replying to wl_surface_frame even though the
surface is not drawn so that XWayland can continue updating the content (to
actual content) before we actually start to draw the window.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20150910/d1253416/attachment-0001.html>