We're not currently using this, and dropping it allows us to loose
a bunch of code which leads us towards the goal of having GdkWindow
only for toplevels (and reparenting makes not sense for toplevels).
We can't really support these on e.g. wayland anyway, and we're trying
to get rid of subwindow at totally in the long term, so lets drop this.
It allows us to drop a lot of complexity.
gdk_window_create_vulkan_context() now exists and will return a Vulkan
context for the given window. It even initializes the surface. But it
doesn't do anything useful yet.
... instead of a gl context.
This requires some refactoring in the way we mark the shared context as
drawing: We now call begin_frame/end_frame() on it and ignore the call
on the main context.
Unfortunately we need to do this check in all vfuncs, which sucks. But I
haven't found a better way.
These complicate a lot of GdkWindow internals to implement features
that not a lot of apps use, and will be better achieved using gsk.
So, we just drop it all.
This is an attempt to get rid of gdk_window_new() for more specific use
cases. These 2 are for client-side windows - regular ones and input-only
ones resepectively.
So far all those functions just call into gdk_window_new().
The update tracking code was ugly and using deprecated drawing APIs. It
was also in the wrong place.
So instead of trying to keep it working, I'll remove it. We need to find
a better way to put it and make it work there.
And with it, gtk_widget_get_visual() and gtk_widget_set_visual() are
gone.
We now always use the RGBA visual (if available) and otherwise fall back
to the system visual.
The cursor was set using gdk_window_set_cursor() even in
gdk_window_new().
So instead of having yet another flag, just make the users of that flag
call gdk_window_set_cursor() directly after the window was created.
X11 was the only backend to support it and people can just override it
using XSetClassHint() directly.
The docs already advertised the function as "Do not use".
Keep the existing call to XSetClassHint() in place, so that we keep
setting the same values as in GTK3.
Instead of giving out Cairo contexts, GdkWindow should provide a
"drawing context", which can then create Cairo contexts on demand; this
allows us to future proof the API for when we're going to use a
different rendering pipeline, like OpenGL.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
Existing code drawing on a GDK window has to handle the direct drawing
and the buffered drawing by itself, by checking the window type and
whether or not the window is backed by a native windowing surface. After
that, the calling code has to create a Cairo context from the window and
keep an association between the context and the window itself.
This is completely unnecessary: GDK can determine whether or not it
should use a backing store to draw on a GdkWindow as well as create a
Cairo context, and keep track of it.
This allows to simplify the calling code, and enforce some of the
drawing behavior we want to guarantee to users.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
An pass_through window is something you can draw in but does not
affect event handling. Normally if a window has with no event mask set
for a particular event then input events in it go to its parent window
(X11 semantics), whereas if pass_through is enabled the window below
the window will get the event. The later mode is useful when the
window is partially transparent. Note that an pass-through windows can
have child windows that are not pass-through so they can still get events
on some parts.
Semantically, this behaves the same as an regular window with
gdk_window_set_child_input_shapes() called on it (and re-called any
time a child is changed), but its far more efficient and easy to use.
This allows us to fix the testoverlay input stacking test.
https://bugzilla.gnome.org/show_bug.cgi?id=750568https://bugs.freedesktop.org/show_bug.cgi?id=90917
Now that we have a two-stages GL context creation sequence, we can move
the profile to a pre-realize option, like the debug and forward
compatibility bits, or the GL version to use.
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
