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
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.txthttps://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
The default ->upload_texture() works also for Windows since commit 27cf0fa,
as some of the problems described in 742953 also applied for GL core
contexts on Windows as well before 27cf0fa. Clean up the GDK-Win32 code a
little bit as a result.
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.
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
We need this because it fixes menu activation. The menu activation code
looks at the time between events to determine if mouse clicks happen too
quickly.
Commit ff256956b2 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
This function is given a barely setup GdkEvent, so the GdkDevice field
is still unset, causing warnings and misbehaviors when the position
is queried for it.
Given that the wintab GTK+ code seems to rely somewhat hard on the wintab
device managing the pointer cursor, query the pointer position from the
pointer itself.
https://bugzilla.gnome.org/show_bug.cgi?id=743330
The window used NULL as a parent window, which defaults internally to
using the root window of the default screen. But at the time wintab is
initialized, there is no default display/screen yet.
Fix this by retrieving this information from the given GdkDeviceManager,
so we don't have to wait for the display to be in place before
initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=743330
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
