1. 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
  2. 24 Jan, 2015 1 commit
  3. 18 Jan, 2015 2 commits
  4. 22 Nov, 2014 2 commits
  5. 20 Nov, 2014 1 commit
  6. 10 Nov, 2014 4 commits
  7. 08 Nov, 2014 2 commits
  8. 07 Nov, 2014 1 commit
  9. 06 Nov, 2014 4 commits
  10. 30 Oct, 2014 1 commit
  11. 28 Oct, 2014 5 commits
  12. 27 Oct, 2014 2 commits
  13. 16 Oct, 2014 1 commit
    • Benjamin Otte's avatar
      gdk: Add GDK_DEBUG=nogl · 672a67d0
      Benjamin Otte authored
      This is mostly useful for fallback testing.
      I suppose if people want finer grained GL ability testing, they can use
      Mesa environment variables to tune things.
  14. 15 Oct, 2014 1 commit
  15. 13 Oct, 2014 7 commits
    • Matthias Clasen's avatar
      Correct Since tags · 7a80c3b0
      Matthias Clasen authored
    • Alexander Larsson's avatar
      gl: Make gdk_gl_context_make_current() return void · fdeb4f8c
      Alexander Larsson authored
      Its not really reasonable to handle failures to make_current, it
      basically only happens if you pass invalid arguments to it, and
      thats not something we trap on similar things on the X drawing side.
      If GL is not supported that should be handled by the context creation
      failing, and anything going wrong after that is essentially a critical
      (or an async X error).
    • Alexander Larsson's avatar
      gl: Make all user GdkGLContexts not attached to any window · 236d08c3
      Alexander Larsson authored
      We make user facing gl contexts not attached to a surface if possible,
      or attached to dummy surfaces. This means nothing can accidentally
      read/write to the toplevel back buffer.
    • Alexander Larsson's avatar
      Add GDK_ALWAYS_USE_GL debug hack · 87970ea2
      Alexander Larsson authored
      If this is set we always use GL to render each window, even
      if there are no GL widgets in the window.
    • 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
    • Alexander Larsson's avatar
      Add gdk_window_mark_paint_from_clip and call from widget drawing · d0147a6f
      Alexander Larsson authored
      This is a new function that gets called every time we're drawing
      some area in the Gtk paint machinery. It is a no-op right now, but
      it will be required later to keep track of what areas which
      we previously rendered with GL was overwritten with cairo contents.
    • Alexander Larsson's avatar
      Change the way the update area is tracked during paint · a8f11835
      Alexander Larsson authored
      First of all we track the current update area during an
      update in window->active_update_area. This will be used later
      in end_paint to know the damaged area.
      Secondly we keep track of old update areas for the last 2
      frames. This will later allow us to reuse old framebuffer
      contents in double or tripple buffer setups, only painting
      what has changed since then.
  16. 12 Oct, 2014 1 commit
  17. 06 Oct, 2014 3 commits
  18. 05 Oct, 2014 1 commit
    • Benjamin Otte's avatar
      gdk: Remove overeager checks · 66be6a01
      Benjamin Otte authored
      Parent is guaranteed to not be NULL. It can only ever be NULL for root
      windows and root windows cannot be created with gdk_window_new() and
      gdk_window_ensure_native() will exit early because they already are
      Also, both functions would crash a few lines below where parent gets