Commit Graph

58 Commits

Author SHA1 Message Date
Alexander Larsson
fb50015519 GdkGLContext: Change the way we track the current context
To properly support multithreaded use we use a global GPrivate
to track the current context. Since we also don't need to track
the current context on the display we move gdk_display_destroy_gl_context
to GdkGLContext::discard.
2014-10-30 12:43:03 +01:00
Alexander Larsson
72a6459d73 gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB 2014-10-27 21:17:08 +01:00
Alexander Larsson
3013997e23 Rename gdk_gl_context_flush_buffer to gdk_gl_context_end_frame
This makes a lot more sense.
2014-10-27 16:33:37 +01:00
Matthias Clasen
98904b8910 Nitpicky documentation changes 2014-10-13 10:43:32 -04:00
Matthias Clasen
706a7064a0 Trivial formatting fixes 2014-10-13 10:43:32 -04:00
Alexander Larsson
fdeb4f8c16 gl: Make gdk_gl_context_make_current() return void
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).
2014-10-13 10:43:32 -04:00
Alexander Larsson
236d08c3c5 gl: Make all user GdkGLContexts not attached to any window
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.
2014-10-13 10:43:31 -04:00
Alexander Larsson
038aac6275 gdk: Add support for OpenGL
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.
2014-10-13 10:43:31 -04:00