GitLab

We simply don't want to care about legacy OpenGL.

All supported platforms also have support for OpenGL ≥ 3.2; it would
complicate the internal code; and would force us to use legacy GL
contexts internally if the first context created by the user is a legacy
GL context, and disable creation of core-3.2 contexts after that.

We will need to fix all our code examples to use the Core 3.2 profile.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

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

Since gboolean is a typedef for int, the compiler won't complain
about gdk_window_set_event_compression (w, 2). So, make it work.

https://bugzilla.gnome.org/show_bug.cgi?id=742566

Commit ff256956 introduced a frame_clock_events_paused
flag, but only ever set it to TRUE, instead of unsetting it when
events are resumed. This was leading to assertion failures in
_gdk_display_unpause_events().

If we are disconnecting from a frame clock that has paused event
processing and hasn't issued a resume yet make sure we resume the
events or they will stay blocked forever.

https://bugzilla.gnome.org/show_bug.cgi?id=742636

In some layouts this inconsistency results in crashes in
gdk_gl_texture_from_surface() since it uses gdk_gl_context_get_window() but
the returned window is not the same as the one that is being painted so
"window->current_paint.surface" is NULL. I saw this problem when packing a
GdkGLArea into a GtkPaned.

https://bugzilla.gnome.org/show_bug.cgi?id=743146

- 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
returned.

- Fix GL painting by removing GL calls that have been depricated by the 3.2 core
profile.

- Additionally remove glInvalidateFramebuffer() call, it is not supported by 3.2
core.

https://bugzilla.gnome.org/show_bug.cgi?id=742953

No need to risk valgrind complaints about initialized
values.

https://bugzilla.gnome.org/show_bug.cgi?id=743422

https://bugzilla.gnome.org/show_bug.cgi?id=743037

We shouldn't recommend gtk_widget_modify_bg() or
gtk_style_set_background() anymore.

This has been bothering me for a while.

It's unused. At the same time, rename "begin_paint_region" to
"begin_paint". This will help us clean up how GDK painting works
in the future to allow more creative use of double-buffering.

This is required for the X backend GL integration. If the
window has a height that is not a multiple of the window scale
we can't properly do the y coordinate flipping that GL needs.
Other backends can ignore this and use the default implementation.

https://bugzilla.gnome.org/show_bug.cgi?id=739750

Add private API to set this per-display, and make the existing
gdk_window_set_debug_update function set a global default.

This is in preparation for making it runtime-settable in the
inspector.

This is needed for cairo_set_device_scale()

It seems in cairo 1.14 we need this after having painted an image surface
to a X11 window surface (i.e. with GDK_RENDERING=image).

These are the last two global GDK symbols that have a libgtk_only
suffix.

https://bugzilla.gnome.org/show_bug.cgi?id=739781

This allows us to use the GDK_PRIVATE_CALL macro inside gtk.

https://bugzilla.gnome.org/show_bug.cgi?id=739781

This will be used in the inspector.

If buffer age is undefined and the updated area is not the whole
window then we use bit-blits instead of swap-buffers to end the
frame.

This allows us to not repaint the entire window unnecessarily if
buffer_age is not supported, like e.g. with DRI2.

This moves the GDK_ALWAYS_USE_GL env var to GDK_GL=always.
It also changes GDK_DEBUG=nogl to GDK_GL=disable, as GDK_DEBUG
is really only about debug loggin.

It also adds some completely new flags:

 software-draw-gl:
   Always use software fallback for drawing gl content to a cairo_t.
   This disables the fastpaths that exist for drawing directly to
   a window and instead reads back the pixels into a cairo image
   surface.

 software-draw-surface:
   Always use software fallback for drawing cairo surfaces onto a
   gl-using window.  This disables e.g. texture-from-pixmap on X11.

 software-draw:
   Enables both the above.

If this is supported we avoid a lot of legacy baggage which we don't
need.

Also found by valgrind.

That seems ... counterproductive.

Cursors should not be on a different display than their window /
device, as that would break Wayland.

This makes a lot more sense.

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.

We were leaking cairo regions every time we draw.

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).

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.

If this is set we always use GL to render each window, even
if there are no GL widgets in the window.

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.

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.