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.
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.
Since GLib ≥ 2.41, attempting to release an unlocked mutex will abort(),
as it happens on most systems already.
Given the lack of proper documentation on how to use GDK with threads,
there is code in the wild that does:
gdk_threads_init ();
gdk_init ();
...
gtk_main ();
instead of the idiomatically correct:
gdk_threads_init ();
gdk_threads_enter ();
gtk_init ();
...
gtk_main ();
...
gdk_threads_leave ();
Which means that gtk_main() will try to release the GDK lock, and thus
trigger an error from GLib.
we cannot really fix all the wrong code everywhere, and since it does
not cost us anything, we can work around the issue inside GDK itself, by
trying to acquire the GDK lock inside gdk_threads_leave() with
trylock().
https://bugzilla.gnome.org/show_bug.cgi?id=735428
It's not necessary anymore because gdk_display_manager_get() always
succeeds and the value is independant of when it was called as it's no
longer backend specific.
Add GInitable interface with a default implementation that always
succeeds. This allows backends to override the GInitable implementation
and add their own checks to determine if the backend can be loaded. If
a backend cannot be loaded, GDK can attempt to load the next available
backend.
Since backends may need to read any relevant options (such as the
display flag) to determine if they can be created successfully, this
patch also removes calls that attempt to create the display manager
before the options have been parsed.
https://bugzilla.gnome.org/show_bug.cgi?id=694465
The story is slightly different for applications vs libraries;
make it clear that libraries should continue using the lock so
we don't break applications that haven't been ported to the
'single thread' model yet.
This commit deprecates gdk_threads_init, gdk_threads_enter,
gdk_threads_leave and gdk_threads_set_lock_functions. Using GTK+
from multiple threads does not work at all on Windows, and is
problematic on other platforms as well. We want to move to a world
where all GTK+ calls are made from the main thread.
Use g_main_context_invoke, g_idle_add and related functions if you
need to schedule GTK+ calls from other threads.
http://bugzilla.gnome.org/show_bug.cgi?id=680754
GDK_NATIVE_WINDOWS was a way to keep some old apps running that did weird
things in gtk2. We should not have to carry this forwards in gtk 3.x.
We do however keep a g_warning() call reminding people of this fact to
ease debugging when they try to port their applications.
https://bugzilla.gnome.org/show_bug.cgi?id=644119
This change does not introduce any functionality change, mostly
cosmtic cleanups, like re-linebreak when introduced annotations messed
up indentation or whitespace errors fixes.
