<html>
<head>
<base href="https://bugzilla.gnome.org/" />
</head>
<body><span class="vcard"><a href="page.cgi?id=describeuser.html&login=otaylor%40redhat.com" title="Owen Taylor <otaylor@redhat.com>"> <span class="fn">Owen Taylor</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - Wrong (ultra tiny/small) cursor size on HiDPI screen"
href="https://bugzilla.gnome.org/show_bug.cgi?id=744932">bug 744932</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Attachment #310989 status</td>
<td>none
</td>
<td>needs-work
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Wrong (ultra tiny/small) cursor size on HiDPI screen"
href="https://bugzilla.gnome.org/show_bug.cgi?id=744932#c133">Comment # 133</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Wrong (ultra tiny/small) cursor size on HiDPI screen"
href="https://bugzilla.gnome.org/show_bug.cgi?id=744932">bug 744932</a>
from <span class="vcard"><a href="page.cgi?id=describeuser.html&login=otaylor%40redhat.com" title="Owen Taylor <otaylor@redhat.com>"> <span class="fn">Owen Taylor</span></a>
</span></b>
<pre>Review of <span class=""><a href="attachment.cgi?id=310989&action=diff" name="attach_310989" title="wayland: Introduce XWayland surface role">attachment 310989</a> <a href="attachment.cgi?id=310989&action=edit" title="wayland: Introduce XWayland surface role">[details]</a></span> <a href='review?bug=744932&attachment=310989'>[review]</a>:
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>