1. 14 Mar, 2015 1 commit
  2. 17 Feb, 2015 1 commit
    • Emmanuele Bassi's avatar
      glarea: Better error handling · 0a4879b9
      Emmanuele Bassi authored
      Currently, GtkGLArea will leak GError instances set during the context
      creation, if an error is set.
      If any error is set post-context creation, it should be displayed even
      in the case a GL context exists; for instance, we can use the error
      display facility for shader compilation errors.
  3. 16 Feb, 2015 1 commit
  4. 15 Feb, 2015 1 commit
  5. 12 Feb, 2015 4 commits
  6. 09 Feb, 2015 2 commits
    • Emmanuele Bassi's avatar
      glarea: Do not use extension API · 5a3b28aa
      Emmanuele Bassi authored
      We are using GL contexts with Core GL profiles, so we need to use the
      proper API, not the one provided by extensions.
    • Emmanuele Bassi's avatar
      GL: Split GL context creation in two phases · 22e6f37c
      Emmanuele Bassi authored
      One of the major requests by OpenGL users has been the ability to
      specify settings when creating a GL context, like the version to use
      or whether the debug support should be enabled.
      We have a couple of requirements in terms of API:
       • avoid, if at all possible, the "C arrays of integers with
         attribute, value pairs", which are hard to write and hard
         to bind in non-C languages.
       • allow failing in a recoverable way.
       • do not make the GL context creation API a mess of arguments.
      Looking at prior art, it seems that a common pattern is to split the
      construction phase in two:
       • a first phase that creates a GL context wrapper object and
         does preliminary checks on the environment.
       • a second phase that creates the backend-specific GL object.
      We adopted a similar pattern:
       • gdk_window_create_gl_context() creates a GdkGLContext
       • gdk_gl_context_realize() creates the underlying resources
      Calling gdk_gl_context_make_current() also realizes the context, so
      simple GL users do not need to care. Advanced users will want to
      call gdk_window_create_gl_context(), set up the optional requirements,
      and then call gdk_gl_context_realize(). If either of these two steps
      fails, it's possible to recover by changing the requirements, or simply
      creating a new GdkGLContext instance.
  7. 31 Jan, 2015 1 commit
  8. 28 Jan, 2015 1 commit
    • Niels Nesse's avatar
      Fix core context creation in GdkGLContext · 27cf0fa3
      Niels Nesse authored
      - Specifically request GL version when creating context. Just specifying core
      profile bit results in the requested version defaulting to 1.0 which causes
      the core profile bit to be ignored and an arbitrary compatability context to be
      - Fix GL painting by removing GL calls that have been depricated by the 3.2 core
      - Additionally remove glInvalidateFramebuffer() call, it is not supported by 3.2
  9. 16 Dec, 2014 2 commits
    • Alexander Larsson's avatar
      GtkGLArea: Handle window scale factor changes · b52a06ac
      Alexander Larsson authored
      We need to re-allocate the buffers for the new gl size.
    • Alexander Larsson's avatar
      GtkGLArea: Only re-allocate buffers during paint · 08853c73
      Alexander Larsson authored
      This drops the maybe_allocate_buffers that re-allocates buffers
      at any point. Instead we just set have_buffers to FALSE and have
      the buffers re-created when needed.
      This also makes the buffer creation code imdeponent and makes it
      clean up no longer needed buffers in order to handle being called
      multiple times due to the above.
      We also ensure we re-allocate the buffers when we're resizing
      and the buffers are already created.
  10. 23 Nov, 2014 2 commits
  11. 03 Nov, 2014 3 commits
  12. 30 Oct, 2014 6 commits
    • Alexander Larsson's avatar
      GdkGLArea: fix has_alpha changes at runtime · f66060c4
      Alexander Larsson authored
      We need to completely reallocate the buffers if we switch
      has_alpha, because we may switch from render buffers to
    • Alexander Larsson's avatar
      GtkGLArea: Add resize signal · 37d0159a
      Alexander Larsson authored
      This is very useful, as almost all GL code wants to recalculate
      the cameras each time the window size changes.
    • Alexander Larsson's avatar
      GtkGLArea: Add profile property · 969b9c65
      Alexander Larsson authored
      This lets you force a core 3.2 context if you want
    • Alexander Larsson's avatar
    • Alexander Larsson's avatar
      GtkGLArea: Major reworking · 5ea3a102
      Alexander Larsson authored
      This restructures the way buffers are allocated and bound in a way
      that is more flexible.
      Buffer operation happens in three phases:
      create_buffer() - Creates the gl objects
      allocate_buffers() - Allocates space for the buffers at a given size
      attach_buffers() - Attaches the buffers to the framebuffer and makes
                         the framebuffer the default drawing target
      And destroy via
      We call all these the first draw, and after that we allocate buffers
      each time the widget changes size until the buffers are deleted.
      We delete the buffers at unrealize.
      However, anyone that wants to manually control buffer allocation strategies
      can manually call allocate/delete_buffers().
      There are also some other changes:
      * Support for stencil buffers.
      * A manual render mode where ::draw doesn't render unless you manually
        invalidated the previous rendering.
    • Alexander Larsson's avatar
      GtkGLArea: Always destroy context on unrealize · ad30262f
      Alexander Larsson authored
      We had some code that tried to reuse the context over realize, but
      that doesn't work as we need to share with the possibly new
      paint context of the re-realized window.
  13. 16 Oct, 2014 1 commit
  14. 13 Oct, 2014 4 commits