GitLab

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.

Using IsModifierKey for now