[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 #146 from Jonas Ådahl <jadahl at gmail.com> ---
(In reply to Owen Taylor from comment #143)
> Review of attachment 309854 [details] [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.

-- 
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/20150911/d480d501/attachment.html>