<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#c146">Comment # 146</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#c143">comment #143</a>) > Review of <a href="attachment.cgi?id=309854&action=diff" name="attach_309854" title="wayland: Introduce XWayland surface role">attachment 309854</a> <a href="attachment.cgi?id=309854&action=edit" title="wayland: Introduce XWayland surface role">[details]</a> <a href='review?bug=744932&attachment=309854'>[review]</a> [review]: > > ::: src/wayland/meta-wayland-surface.c > @@ +566,3 @@ > + * - Go through the surface actors frame callback list until some > time after > + * it has been mapped so can avoid wasting buffers when the window > is > + * hidden. > > I'd like for us to say say: > > /* For Xwayland windows, throttling frames when the window isn't > * actually drawn is less useful, because Xwayland still has to do > * the drawing sent from the application - the throttling would only > * be of sending us damage messages, so we simplify and send frame callbacks > * after the next paint of the screen, whether the window was drawn > * or not. > * > * Currently in *some* cases we also seem to take a few frames before > * we draw the window, for not completely understood reasons, and in > * that case, not thottling frame callbacks to drawing has the > * happy side effect that we avoid showing the user the initial black > * frame from when the window is mapped empty. > */ "Some cases" is a bit misleading. From my testing, the only X clients that we seem to draw immediately after the role is assigned are GTK+ 3 clients, and this seems to be because GTK+ 3 implies MapNotify and creates the wl_surface a while after MapRequest while xterm, gitk, QT, GTK+ 2.0 all do MapRequest/MapNotify wl_surface creation up front. > > I can't find anything the code that intentionally tries to only show > Xwayland windows on the second frame, and when I add printfs, I don't see > this behavior - for me the first commit seems to be drawn with an already > shown window. Reading the code looks like to me that Xwayland windows are > shown only based on X traffic, without regard to wayland. I looked a bit more, and we do show XWayland MetaWindows up front when receiving MapRequest/MapNotify, sometimes long before it is possible to draw it (before we assigned a surface to it). A difference between GTK+ 3 X11 clients and other X11 clients is that for GTK+ 3 clients, Xwayland creates the wl_surface a while after we receive MapRequest (i.e. create and show the MetaWindow). So, an observation I did was that no matter the client, the content tend to be drawn the third frame after we create (and show) the MetaWindow. For GTK+ 3 clients, this may be the the frame after the window<->wl_surface association is done. For other clients, its looks like it takes a frame or two more for it to be drawn, but its still seem to be usually three frames after the MetaWindow creation. I don't know what is causing the extra frames between the surface<->window association and the actual painting though. > > I suppose there perhaps is some sequence of, depending on the ordering of: > > receiving the WL_SURFACE_ID message > receiving the MapRequest/MapNotify message > the commit messages > > where things occur as you've noted, but I can't work out what is, and it > definitely doesn't seem intentional or reliable.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>