1. 25 Apr, 2016 3 commits
    • Emmanuele Bassi's avatar
      gl: Use a uniform to flip R and B colors on GLES · f848450a
      Emmanuele Bassi authored
      This allows us to decide when the R and B color channels should be
      flipped with a much better granularity.
      
      For instance, when using GLX_EXT_texture_from_pixmap to create a GL
      texture from a surface we don't need to swap the R and B channels, as
      the internal representation of the texture data will already have the
      appropriate colors.
      
      We also don't need to flip color channels when blitting from a texture.
      f848450a
    • Emmanuele Bassi's avatar
      gl: Add more OpenGL ES checks · 1620b7bd
      Emmanuele Bassi authored
      Check for the appropriate extensions depending on which type of API
      we're using.
      1620b7bd
    • Emmanuele Bassi's avatar
      gl: Add 'use-es' flag · e1cecd24
      Emmanuele Bassi authored
      On some platforms we can ask the GL context machinery to create a GLES
      context, instead of a GL one.
      
      In order to ask for a GLES context at GdkGLContext realization time, we
      use a bit field like we do for forward compatible, or debug contexts.
      
      The 'use-es' bit also changes the way we select a default version,
      because OpenGL and OpenGLES versions differ.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=743746
      e1cecd24
  2. 07 Oct, 2015 2 commits
    • Emmanuele Bassi's avatar
      gl: Store the legacy bit in the GL program data · 24230ca7
      Emmanuele Bassi authored
      We need to know if we're using a legacy GL context in various places.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=756142
      24230ca7
    • Emmanuele Bassi's avatar
      gdk: Allow querying if a GL context is in legacy mode · 2dfca143
      Emmanuele Bassi authored
      We want to have the ability to fall back to legacy GL contexts when
      creating them. In order to do so, we need to store the legacy bit on the
      GdkGLContext, as well as being able to query it.
      
      Setting the legacy bit from outside GDK is not possible; we cannot
      create GL contexts in 3.2 core profile *and* compatibility modes at the
      same time, and if we allowed users to select the legacy mode themselves,
      it would break the creation of the GdkWindow's paint GL context.
      
      What we do allow is falling back to legacy GL context if the platform
      does not support 3.2 core profiles — for instance, on older GPUs or
      inside virtualized environments.
      
      We are also going to use the legacy bit internally, to choose which GL
      API we can use when drawing GL content.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=756142
      2dfca143
  3. 09 Feb, 2015 4 commits
    • Emmanuele Bassi's avatar
      gl: Drop GdkGLContextClass.upload_texture() · 843475bd
      Emmanuele Bassi authored
      It's unnecessary to allow per-backend overrides.
      843475bd
    • Emmanuele Bassi's avatar
      gl: Move getters for context options to the public API · 6aaa6c33
      Emmanuele Bassi authored
      They can be useful for third party code as well.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=741946
      6aaa6c33
    • Emmanuele Bassi's avatar
      gl: Add context options · fa900522
      Emmanuele Bassi authored
      Users of the GdkGLContext API should be allowed to set properties on the
      shim GdkGLContext instance prior to realization, so that the
      backend-specific implementation can use the value of those properties
      when creating the windowing system specific resources.
      
      The main three options are:
      
       • a major/minor version tuple, to request a specific GL version
       • a debug bit, to request a "debug context", which provides additional
         validation and run time checking
       • a forward compatibility bit, to request a context that does not
         have deprecated functionality
      
      See also:
       - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt
      
      https://bugzilla.gnome.org/show_bug.cgi?id=741946
      fa900522
    • 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.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=741946
      22e6f37c
  4. 17 Dec, 2014 1 commit
    • Chun-wei Fan's avatar
      gdkgl: Use vfunc For Uploading Textures · 9fd9f61b
      Chun-wei Fan authored
      As the alignments, strides and image formats may be different across
      platforms, make the texture upload a vfunc to allow backends to override
      the GL commands for uploading textures for the software implementation for
      gdk_gl_texture_from_surface(), if necessary.
      
      Suggested by Alex to avoid copying non-trivial portions of code which would
      then add maintainenace burden.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=740795
      9fd9f61b
  5. 22 Nov, 2014 2 commits
  6. 20 Nov, 2014 1 commit
  7. 06 Nov, 2014 5 commits
  8. 30 Oct, 2014 1 commit
  9. 27 Oct, 2014 2 commits
  10. 13 Oct, 2014 1 commit
    • Alexander Larsson's avatar
      gdk: Add support for OpenGL · 038aac62
      Alexander Larsson authored
      This adds the new type GdkGLContext that wraps an OpenGL context for a
      particular native window. It also adds support for the gdk paint
      machinery to use OpenGL to draw everything. As soon as anyone creates
      a GL context for a native window we create a "paint context" for that
      GdkWindow and switch to using GL for painting it.
      
      This commit contains only an implementation for X11 (using GLX).
      
      The way painting works is that all client gl contexts draw into
      offscreen buffers rather than directly to the back buffer, and the
      way something gets onto the window is by using gdk_cairo_draw_from_gl()
      to draw part of that buffer onto the draw cairo context.
      
      As a fallback (if we're doing redirected drawing or some effect like a
      cairo_push_group()) we read back the gl buffer into memory and composite
      using cairo. This means that GL rendering works in all cases, including
      rendering to a PDF. However, this is not particularly fast.
      
      In the *typical* case, where we're drawing directly to the window in
      the regular paint loop we hit the fast path. The fast path uses opengl
      to draw the buffer to the window back buffer, either by blitting or
      texturing. Then we track the region that was drawn, and when the draw
      ends we paint the normal cairo surface to the window (using
      texture-from-pixmap in the X11 case, or texture from cairo image
      otherwise) in the regions where there is no gl painted.
      
      There are some complexities wrt layering of gl and cairo areas though:
      * We track via gdk_window_mark_paint_from_clip() whenever gtk is
        painting over a region we previously rendered with opengl
        (flushed_region). This area (needs_blend_region) is blended
        rather than copied at the end of the frame.
      * If we're drawing a gl texture with alpha we first copy the current
        cairo_surface inside the target region to the back buffer before
        we blend over it.
      
      These two operations allow us full stacking of transparent gl and cairo
      regions.
      038aac62