Commit d249e77 (API: screen: Remove gdk_screen_is_composited()) attempted
to update the GDK-Win32 for the removal of the API, but some parts were
missed. This updates the code so that things continue to build and run.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Update the GDKGL implementation:
-Allow legacy contexts to be created.
-Use finer-grained attributes to ask for a pixel format when possible,
which also adds support for anti-aliasing
In fact the changes here are required for GTKGL to work properly on
Windows for 4.x.
Note that creation of gles contexts is not done here, as the system does
not support such contexts directly on Windows, but only through means such
as ANGLE, which is a totally different issue here.
https://bugzilla.gnome.org/show_bug.cgi?id=773528
Other portions of the GDK-Win32 backend make use of this function as
layered windows need to be disabled for GL windows and possibly other
parts, so make this function a private function that is available within
the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=763285
Layered windows and GL do not work well together, so disable layered
windows when initiating a GdkGLContext, so that GtkGLArea programs can run
properly.
Also based on patch by LRN to address the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=763080
We now have proper checks for gdk_screen_is_composited() and a proper
implementation for gdk_screen_get_rgba_visual() for Windows, so we
can remove the comments in this file stating that they aren't
available for Windows.
The existence of OpenGL implementations that do not provide the full
core profile compatibility because of reasons beyond the technical, like
llvmpipe not implementing floating point buffers, makes the existence of
GdkGLProfile and documenting the fact that we use core profiles a bit
harder.
Since we do not have any existing profile except the default, we can
remove the GdkGLProfile and its related API from GDK and GTK+, and sweep
the whole thing under the carpet, while we wait for an extension that
lets us ask for the most compatible profile possible.
https://bugzilla.gnome.org/show_bug.cgi?id=744407
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.
Emit an error if the profile is different.
This is a follow-up commit to commits cc45e82 (x11/gl: Ensure we use the
3.2 core profile) and 2d9081d (wayland/gl: Ensure we use the 3.2 core
profile), so that we do the same on GDK-Win32. Update variable names and
comments so that the code is clearer to people, as we still need a
temporary legacy WGL context first before we can use
wglCreateContextAttribsARB() to create a WGL core (3.2+) context.
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
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.
This adds support for OpenGL to the GDK Windows backend using the WGL API
calls, which enables programs that uses the GTK+ GLArea widgets to work on
Windows as well.
This also adds a simple utility function to query for the version of OpenGL
that is supported by the Windows system, like the one provided by the X11
backend.
Many thanks to Alex (and Emmanuele, who started the OpenGL integration in
GTK+) who offered advice and help along the way, as well as the X11 and
Wayland backend for this work to refer to and to model upon.
https://bugzilla.gnome.org/show_bug.cgi?id=740795
