[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

Owen Taylor <otaylor at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #310989|none                        |needs-work
             status|                            |

--- Comment #133 from Owen Taylor <otaylor at redhat.com> ---
Review of attachment 310989:

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.

-- 
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/20150909/2c8290a0/attachment.html>