1. 18 Mar, 2014 1 commit
  2. 28 Feb, 2014 1 commit
  3. 27 Feb, 2014 2 commits
  4. 20 Feb, 2014 1 commit
    • 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
          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.
  5. 19 Feb, 2014 1 commit
  6. 18 Feb, 2014 1 commit
  7. 07 Feb, 2014 1 commit
  8. 01 Feb, 2014 1 commit
    • Jasper St. Pierre's avatar
      Start moving X11-specific code to window-x11.c · f7097e6f
      Jasper St. Pierre authored
      The goal here is to make MetaWindow represent a toplevel, managed window,
      regardless of if it's X11 or Wayland, and build an abstraction layer up.
      Right now, most of the X11 code is in core/ and the wayland code in wayland/,
      but in the future, I want to move a lot of the X11 code to a new toplevel, x11/.
  9. 22 Jan, 2014 2 commits
  10. 25 Nov, 2013 1 commit
    • Jasper St. Pierre's avatar
      cullable: Turn cull_out / reset_culling into a separate interface · 74e43a47
      Jasper St. Pierre authored
      Instead of hardcoded knowledge of certain classes in MetaWindowGroup,
      create a generic interface that all actors can implement to get parts of
      their regions culled out during redraw, without needing any special
      knowledge of how to handle a specific actor.
      The names now are a bit suspect. MetaBackgroundGroup is a simple
      MetaCullable that knows how to cull children, and MetaWindowGroup is the
      "toplevel" cullable that computes the initial two regions. A future
      cleanup here could be to merge MetaWindowGroup / MetaBackgroundGroup so
      that we only have a generic MetaSimpleCullable, and move the "toplevel"
      cullability to be a MetaCullableToplevel.
  11. 19 Nov, 2013 4 commits
    • Jasper St. Pierre's avatar
      Fix build · 392e2248
      Jasper St. Pierre authored
      Forgot to delete the line above it when cherry-picking... oops.
    • Rico Tzschichholz's avatar
    • Rico Tzschichholz's avatar
    • Jonas Ådahl's avatar
      Introduce MetaSurfaceActor for drawing MetaWindowActor content · ea916b6c
      Jonas Ådahl authored
      Instead of having MetaWindowActor only have one single MetaShapedTexture
      as actor drawing its content, introduce a new abstract MetaSurfaceActor
      that takes care of drawing.
      This is one step in the direction to decouple MetaWaylandSurface with a
      MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order
      to finally support subsurfaces like features, or any feature where
      window is not drawn using a single texture.
      The first step, implemented in this patch, is to not have
      MetaWindowActor work directly with a shaped texture. There are still
      some cases where it simply gets the texture and goes on as before, but
      this should be changed by either removing the need of going via
      MetaWindowActor or by adding some generic interface to MetaSurfaceActor
      that doesn't limit its functionality to one shaped texture.
      There should be no visible difference nor after this patch, but
      meta_window_actor_get_texture() and meta_surface_actor_get_texture()
      should be deprecated when equivalent functionality has been introduced.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
  12. 12 Nov, 2013 1 commit
  13. 29 Oct, 2013 1 commit
  14. 15 Sep, 2013 1 commit
  15. 11 Sep, 2013 1 commit
  16. 10 Sep, 2013 1 commit
  17. 03 Sep, 2013 4 commits
  18. 30 Aug, 2013 4 commits
  19. 26 Aug, 2013 4 commits
  20. 23 Aug, 2013 2 commits
  21. 19 Aug, 2013 1 commit
  22. 17 Aug, 2013 4 commits