<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <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#c137">Comment # 137</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 <a href="page.cgi?id=describeuser.html&login=jadahl%40gmail.com" title="Jonas Ådahl <jadahl@gmail.com>"> Jonas Ådahl</a> <pre>(In reply to Owen Taylor from <a href="show_bug.cgi?id=744932#c133">comment #133</a>) > Review of <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> <a href='review?bug=744932&attachment=310989'>[review]</a> [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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>