1. 23 Sep, 2022 1 commit
  2. 04 Jun, 2022 1 commit
  3. 02 Mar, 2022 1 commit
    • Christian Hergert's avatar
      macos: use GdkMacosBuffer for storing damage region · bdd53930
      Christian Hergert authored
      The GdkMacosBuffer object already has storage for tracking the damage
      region as it is used in GdkMacosCairoContext to manually copy regions from
      the front buffer to the back buffer. This makes the GdkMacosGLContext also
      use that field so that we can easily drop old damage regions when the
      buffer is lost. This happens during resizes, monitor changes, etc.
  4. 22 Feb, 2022 3 commits
    • Christian Hergert's avatar
    • Christian Hergert's avatar
      macos: force pixel format without depth/stencil · 76a58c40
      Christian Hergert authored
      We don't need either depth or stencil buffers, so we want a pixel format
      without them so that things like glClear() can do less work.
    • Christian Hergert's avatar
      macos: use CALayer and IOSurface for rendering · 8b71cff7
      Christian Hergert authored
      This provides a major shift in how we draw both when accelerated OpenGL
      as well as software rendering with Cairo. In short, it uses tiles of Core
      Animation's CALayer to display contents from an OpenGL or Cairo rendering
      so that the window can provide partial damage updates. Partial damage is
      not generally available when using OpenGL as the whole buffer is flipped
      even if you only submitted a small change using a scissor rect.
      Thankfully, this speeds up Cairo rendering a bit too by using IOSurface to
      upload contents to the display server. We use the tiling system we do for
      OpenGL which reduces overall complexity and differences between them.
      A New Buffer
      GdkMacosBuffer is a wrapper around an IOSurfaceRef. The term buffer was
      used because 1) surface is already used and 2) it loosely maps to a
      front/back buffer semantic.
      However, it appears that IOSurfaceRef contents are being retained in
      some fashion (likely in the compositor result) so we can ...
  5. 03 Nov, 2021 1 commit
  6. 08 Oct, 2021 1 commit
    • Benjamin Otte's avatar
      gl: Check allowed APIs in realize() · f584d4f5
      Benjamin Otte authored
      Add gdk_gl_context_is_api_allowed() for backends and make them use it.
      Finally, have them return the final API as the return value (or 0 on
      And then use that api instead of a use_es boolean flag.
      Fixes #4221
  7. 06 Oct, 2021 2 commits
    • Benjamin Otte's avatar
      gdk: hdr => high depth · dc6e8315
      Benjamin Otte authored
      The term "hdr" is so overloaded, we shouldn't use them anywhere, except
      from maybe describing all of this work in blog posts and other marketing
      So do renames:
      * hdr => high_depth
      * request_hdr => prefers_high_depth
      This more accurately describes what is going on.
    • Benjamin Otte's avatar
      gdk: Add a request_hdr argument to begin_frame() · 7ede4688
      Benjamin Otte authored
      It's not used by anyone, it's just there.
      gdk_draw_context_begin_frame_full() has been added so renderers can
      make use of it.
  8. 29 Sep, 2021 1 commit
  9. 24 Sep, 2021 2 commits
  10. 23 Sep, 2021 1 commit
    • Benjamin Otte's avatar
      gdk: Make sure only one GL backend is used · 23acc993
      Benjamin Otte authored
      Creative people managed to create an X11 display and a Wayland display
      at once, thereby getting EGL and GLX involved in a fight to the death
      over the ownership of the glFoo() symbolspace.
      A way to force such a fight with available tools here is (on Wayland)
      running something like:
      GTK_INSPECTOR_DISPLAY=:1 GTK_DEBUG=interactive gtk4-demo
      Related: xdg-desktop-portal-gnome#5
  11. 22 Jul, 2021 4 commits
    • Benjamin Otte's avatar
      gdk: Move GL context construction to GdkGLContext · e06e0e85
      Benjamin Otte authored
      Now that we have the display's context to hook into, we can use it to
      construct other GL contexts and don't need a GdkSurface vfunc anymore.
      This has the added benefit that backends can have different GdkGLContext
      classes on the display and get new GLContexts generated from them, so
      we get multiple GL backend support per GDK backend for free.
      I originally wanted to make this a vfunc on GdkGLContextClass, but
      it turns out all the abckends would just call g_object_new() anyway.
    • Benjamin Otte's avatar
      gl: Move vfunc · 9f1d6e1f
      Benjamin Otte authored
      Instead of
      we now have
      This fits better with the backends (we can actually implement
      clearCurrent on macOS now) and makes it easier to implement different GL
      backends for backends (like EGL/GLX on X11).
      We also pass a surfaceless boolean to make_current() so the calling code
      can decide if a surface needs to be bound or not, because the backends
      were all doing whatever, which was very counterproductive.
    • Benjamin Otte's avatar
      gdk: Get rid of paint contexts · 50543634
      Benjamin Otte authored
      ... or more exactly: Only use paint contexts with
      Instead of paint contexts being the only contexts who call swapBuffer(),
      any context can be used for this, when it's used with
      This removes 2 features:
      1. We no longer need a big sharing hierarchy. All contexts are now
         shared with gdk_display_get_gl_context().
      2. There is no longer a difference between attached and non-attached
         contexts. All contexts work the same way.
    • Benjamin Otte's avatar
      gdk: Add GdkDisplay::init_gl vfunc · 430b6f8f
      Benjamin Otte authored
      The vfunc is called to initialize GL and it returns a "base" context
      that GDK then uses as the context all others are shared with. So the GL
      context share tree now looks like:
      + context from init_gl
        - context1
        - context2
      So this is a flat tree now, the complexity is gone.
      The only caveat is that backends now need to create a GL context when
      initializing GL so some refactoring was needed.
      Two new functions have been added:
      * gdk_display_prepare_gl()
        This is public API and can be used to ensure that GL has been
        initialized or if not, retrieve an error to display (or debug-print).
      * gdk_display_get_gl_context()
        This is a private function to retrieve the base context from
        init_gl(). It replaces gdk_surface_get_shared_data_context().
  12. 14 Jun, 2021 1 commit
  13. 24 Mar, 2021 1 commit
  14. 19 Feb, 2021 1 commit
    • Christian Hergert's avatar
      macos: make OpenGL context opaque when possible · b2fd0962
      Christian Hergert authored
      If our opaque region is the entire surface, then we can make the OpenGL
      context opaque like we do for decorated windows. This improves performance
      as the compositor does not need to blend the surface with the contents
      behind the window.
  15. 08 Feb, 2021 3 commits
  16. 07 Dec, 2020 2 commits
  17. 02 Dec, 2020 1 commit
  18. 19 Nov, 2020 1 commit
  19. 05 Nov, 2020 6 commits
  20. 29 Oct, 2020 1 commit
    • Christian Hergert's avatar
      macos: implement GL context · de9c9efa
      Christian Hergert authored
      This implements the basics for a GdkGLContext on macOS. Currently, rendering
      only is fully working for the GskCairoRenderer case where we read back pixels
      into a cairo surface for rendering. More work on synchronization is required for
      the GL on GskGLRenderer case.
      When we attempt to render a surface itself with GL, the context will ensure that
      the new GdkMacosGLView is placed within the NSWindow. In other cases, we
      use a dummy NSView and NSWindow for backing the NSOpenGLContext to
      ensure that we can get accelerated drawing.
      This gets GtkGLArea working when running with GSK_RENDERER=cairo.
  21. 21 Jul, 2020 1 commit
    • Christian Hergert's avatar
      macos: prototype new GDK backend for macOS · 9dbf99d9
      Christian Hergert authored
      This is fairly substantial rewrite of the GDK backend for quartz and
      renamed to macOS to allow for a greenfield implementation.
      Many things have come across from the quartz implementation fairly
      intact such as the eventloop integration design and discovery of
      event windows from the NSEvent.
      However much has been changed to fit in with the new GDK design and
      how removal of child GdkWindow have been completely eliminated.
      Furthermore, the new GdkPopup allows for regular NSWindow to be used
      to provide popovers unlike the previous implementation.
      The object design more closely follows the ideal for a GDK backend.
      Views have been broken out into subclasses so that we can support
      multiple GSK renderer paths such as GL and Cairo (and Metal in the
      future). However mixed mode GL and Cairo will not be supported. Currently
      only the Cairo renderer has been implemented.
      A new frame clock implementation using CVDisplayLink provides more
      accurate information about when to ...