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

They can be useful for third party code as well.

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

Instead of LEGACY.

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

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

Like what is being done in the X11 and Wayland backends, create the
GdkWin32GLContext in 2 steps, where we only create the actual WGL context
in _gdk_win32_gl_context_realize().

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

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

When creating an OpenGL context using the glXCreateContextAttribs()
function.

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

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

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

This way, we can remove it as a separate argument from
gtk_css_value_compute() and allow computation to only depend on one
thing: the style provider.

This guarantees we only create 1 extra style cascade in total for hidpi
and not one per style context.

Style cascades are now nested like this:

GtkSettings root cascade (scale == 1)
 |
 +-- GtkSettings per scale cascade (for any scale, no custom providers)
 |
 +-- GtkStyleContext custom cascade (for any scale, custom providers)

This requires a bunch of care when changing cascade-related properties
inside GtkStyleContext, so that it ends up with a properly setup
cascade, but I think I got those cases right.

The only thing we don't do yet is reverting to a GtkSettings cascade
when the last custom provider is removed from a custom cascade.

This is in preparation for the next commits.

We don't have a Win32-specific ->upload_texture() anymore, so don't
indicate so.  Left out this part from my previous commit.

The default ->upload_texture() works also for Windows since commit 27cf0fa3,
as some of the problems described in 742953 also applied for GL core
contexts on Windows as well before 27cf0fa3.  Clean up the GDK-Win32 code a
little bit as a result.

Introduced in 7eecb164

This property is necessary to ensure widgets automatically update after
the text scale factor is changed desktop-wide.

And if I'm already doing a property like this, I can make it
overridable. So now you can override the dpi per-widget with CSS like
GtkSwitch {
  -gtk-dpi: 48;
}
if you want to debug things.

Long-term, we want to get rid of this property and insist on dpi being
96 everywhere and people can change the font size to get larger fonts.

GPUs generally have problems when you create a 35000px wide surface.
Luckily X catches this and sends a BadAlloc. Which GTK immediately
abort()s on.

Testcase included.

https://bugzilla.redhat.com/show_bug.cgi?id=1163579

We should remove the mir and cairo surface before rendering the
transient_for, which will regenerate the cairo surface anyways.
Otherwise, we end up releasing both, when we only really want to get rid
of the mir surface.

Some child window behaviour is faked by painting in the parent, so we
don't bother creating the Mir surface in that case.

Mouse over a parent menu[bar] didn't work while the menu was open.
The fix was to correct the behaviour of pointer crossing events so that
the pointer appears to be only inside one window at a time.

See: http://tronche.com/gui/x/xlib/events/window-entry-exit/normal.html

Without this, we generate incorrect crossing events for transient
windows.