If GLES support is enabled on Windows, force GLES mode if we are running
on a ARM64 version of Windows (i.e. Windows 10 for ARM).
This is required as ARM64 versions of Windows only provide a software
implementation of OpenGL 1.1/1.2, which is not enough for our purposes.
Thus, we could make instead use the GLES support provided via Google's
libANGLE (which emulates OpenGL/ES 3 with Direct3D 9/11), so that we
can run GtkGLArea programs under OpenGL/ES in ARM64 versions of Windows.
Note that eventually we could update the libepoxy build files for Windows
to not check nor enable WGL when building for ARM64 Windows, as the WGL
items do not work, although they do build.
We need to use GL_BGRA instead of GL_RGBA when doing glReadPixels() on
EGL on Windows (ANGLE) so that the red and blue bits won't be displayed
inverted.
Also fix the logic where we determine whether to bit blit or redraw
everything.
Some implementations of the ES 1.00 shader (such as Google's ANGLE) do
not like the 'f' suffix for floats, so just drop it, as it should be
harmless to drop.
This is for adding a EGL-based renderer which is done via the ANGLE
project, which translate EGL calls to Direct3D 9/11. This is done as a
possible solution to issue #105, especially for cases where the needed
full GL extensions to map OpenGL to Direct3D is unavailable or
unreliable, or when the OpenGL implementation from the graphics drivers
are problematic.
To enable this, do the following:
-Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are
available. A sufficiently-recent ANGLE is needed for things to
work correctly--note that the copy of ANGLE that is included in
qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause
license.
-Build libepoxy on Windows with EGL support enabled.
-Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs
to be set with gl-gles as at least one of the flags.
Known issues:
-Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed
extensions, notably GL_OES_vertex_array_object, but its ES 3 support is
sufficient.
-There is no autodetection or fallback mechanism to enable using
EGL/Angle automatically yet. There are no plans to do this in this
commit.
...EGL support needs to be explicitly enabled during the build of
libepoxy on Windows as it is not enabled by default on Windows.
With this, we can add an EGL renderer for Windows that make use of
Google's libANGLE, which is a library that translates OpenGL/ES calls
to Direct3D 9/11, which will provide better hardware compatibility
on Windows and would act as one of the foundations to resolve issue #105.
Set the accessible role for GtkLinkButton to button.
We don't use the 'link' role since ARIA says "if it
behaves like a button, use 'button'".
Update docs and add a test.
This changes should not be neccessary, since
GtkLinkButton derives from GtkButton, see #2965.
It's not a portable API, so remove it. The corresponding backend
specific functions are still available, if they were implemented, e.g.
gdk_macos_monitor_get_workarea() and gdk_x11_monitor_get_workarea().
pandoc insists on using the xlink namespace for hrefs,
and the namespace setup doesn't carry over xi:includes.
My first fix was to tell pandoc to generate standalone
docbook documents, which makes it insert the xlink
namespace. But it also makes it wrap all sections and
chapters in articles, and that messes up our toc structure.
So, patch things up differently by stripping the xlink:
from hrefs via regex.
Yay for XML!
