Skip to content
  • Jasper St. Pierre's avatar
    window-actor: Split into two subclasses of MetaSurfaceActor · 83aca0b5
    Jasper St. Pierre authored
    The rendering logic before was somewhat complex. We had three independent
    cases to take into account when doing rendering:
    
      * X11 compositor. In this case, we're a traditional X11 compositor,
        not a Wayland compositor. We use XCompositeNameWindowPixmap to get
        the backing pixmap for the window, and deal with the COMPOSITE
        extension messiness.
    
        In this case, meta_is_wayland_compositor() is FALSE.
    
      * Wayland clients. In this case, we're a Wayland compositor managing
        Wayland surfaces. The rendering for this is fairly straightforward,
        as Cogl handles most of the complexity with EGL and SHM buffers...
        Wayland clients give us the input and opaque regions through
        wl_surface.
    
        In this case, meta_is_wayland_compositor() is TRUE and
        priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND.
    
      * XWayland clients. In this case, we're a Wayland compositor, like
        above, and XWayland hands us Wayland surfaces. XWayland handles
        the COMPOSITE extension messiness for us, and hands us a buffer
        like any other Wayland client. We have to fetch the input and
        opaque regions from the X11 window ourselves.
    
        In this case, meta_is_wayland_compositor() is TRUE and
        priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11.
    
    We now split the rendering logic into two subclasses, which are:
    
      * MetaSurfaceActorX11, which handles the X11 compositor case, in that
        it uses XCompositeNameWindowPixmap to get the backing pixmap, and
        deal with all the COMPOSITE extension messiness.
    
      * MetaSurfaceActorWayland, which handles the Wayland compositor case
        for both native Wayland clients and XWayland clients. XWayland handles
        COMPOSITE for us, and handles pushing a surface over through the
        xf86-video-wayland DDX.
    
    Frame sync is still in MetaWindowActor, as it needs to work for both the
    X11 compositor and XWayland client cases. When Wayland's video display
    protocol lands, this will need to be significantly overhauled, as it would
    have to work for any wl_surface, including subsurfaces, so we would need
    surface-level discretion.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=720631
    83aca0b5