Copy what we do in GTK4: Check for GL >= 3.2 or GLES >= 3.0 or the
GL_ARB_sync extension.
Then store that info for a (private) gdk_gl_context_has_sync()
function.
And then check that function before using GLsync objects as introduced
by commit 9811485990.
Fixes#5749
This commit fixes a performance issue on X11 systems making use of the gdk_cairo_draw_from_gl() function in regards
to drawing on an OpenGL surface in GTK/GDK. Specifically, this fix removes the slow X11 codepath that was used when
executing the gdk_cairo_draw_from_gl() function because it was completely uneeded. I tested the before and after on
Flutter and GTK apps making use of the OpenGL rendering and can confirm that there is no behaviour and visual
difference. This change is also specific to drawings that make use of textures. The render buffer code path has
been left completely unmodified.
Closes#4704
GTK+ 3.0 was currently using GL_EXT_framebuffer_object, which is
deprecated as the ARB version has been merged into OpenGL 3.0 as well as
OpenGL ES 2.0, and provides laxer requirements.
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 Direc3D 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. Note also that Visual Studio 2013 or later is required to
build ANGLE from QT-5.10.1, but the 2013-built ANGLE DLLs can work
without without problems for GTK+ that is built with Visual Studio
2008 or later.
-Build libepoxy on Windows with EGL support enabled.
-Define GDK_WIN32_ENABLE_EGL when building gdk-win32.lib when building
with Visual Studio, or pass in --enable-win32-gles during configure
when building with MinGW/mingw-w64.
-Prior to running GTK+ programs, the GDK_GL envvar needs to contain
gles.
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 is no plans to do this in this
commit.
Thanks to LRN for pointing out that we should #include
"win32/gdkwin32.h" instead of #include "gdkwin32.h" for gdkgl.c. LRN
also did the autotools portion of this patch.
Further notes about the autotools --enable-win32-gles option, fom LRN:
This adds --enable-win32-gles option, which enables the
code for GLES renderer. This commit also adds tests for WGL and
EGL in epoxy. The absence of WGL is highly unlikely (it's enabled
by default), but checking for EGL when GLES is enabled is necessary,
as EGL is disabled in Windows builds of epoxy by default.
We check when we realize the GdkGLContext, but we never use the check
before using the API, and it breaks on drivers that do not implement the
extension, or on drivers that only support OpenGL ES 2.0.
This allows us to decide when the R and B color channels should be
flipped with a much better granularity.
For instance, when using GLX_EXT_texture_from_pixmap to create a GL
texture from a surface we don't need to swap the R and B channels, as
the internal representation of the texture data will already have the
appropriate colors.
We also don't need to flip color channels when blitting from a texture.
We cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV when reading back
from the frame buffer in the software fallback path, as they do not
exist on OpenGL ES.
This will make the slow path a bit slower, because of the implicit
format conversion.
If we're using modern GLSL, then we should stop using deprecated
modifiers, like 'varying' and 'attribute', as well as deprecated global
variables, like 'gl_FragColor'.
On the other hand, with legacy contexts we should be using older GLSL
shaders, to maximize compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
Using version 1.20 with a forward compatible 3.2 core context is incorrect
since OpenGL 3.2 deprecates shader version 1.20 (See section E.2). The latest
fglrx drivers will not compile these shaders.
https://bugzilla.gnome.org/show_bug.cgi?id=744203
- 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
As the alignments, strides and image formats may be different across
platforms, make the texture upload a vfunc to allow backends to override
the GL commands for uploading textures for the software implementation for
gdk_gl_texture_from_surface(), if necessary.
Suggested by Alex to avoid copying non-trivial portions of code which would
then add maintainenace burden.
https://bugzilla.gnome.org/show_bug.cgi?id=740795
We can't combine multiple draws into one for the software fallback,
because each quad has a different texture. And we generally don't
want to make a larger single texture because then we would have
to upload more data.
NULL-plus-something could be seen by the compiler to attempt to do
arithmetic with void *, which is a GCCism. Instead, do the math normally
and cast the results as a void *.
https://bugzilla.gnome.org/show_bug.cgi?id=740605
This requires us to use GL_TRIANGLES and six verts per quad instead
of four, which makes me think it might not be worth it on
well-optimized GL drivers. However, from talking to some driver
developers about it, the GL_TRIANGLES should be faster, since this
means that there's one giant contiguous buffer instead of many small
buffers.
If we were really rendering a lot of quads, I'd use an element buffer
and GL_PRIMITIVE_RESTART, but we're really not ever rendering that
many quads, and the setup cost for that would just be too annoying.
This is needed in the edge case where the X11 backend rounded the actual
size, and the GL flipping really needs the correct window height to
do proper Y coordinate flipping.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
This moves the GDK_ALWAYS_USE_GL env var to GDK_GL=always.
It also changes GDK_DEBUG=nogl to GDK_GL=disable, as GDK_DEBUG
is really only about debug loggin.
It also adds some completely new flags:
software-draw-gl:
Always use software fallback for drawing gl content to a cairo_t.
This disables the fastpaths that exist for drawing directly to
a window and instead reads back the pixels into a cairo image
surface.
software-draw-surface:
Always use software fallback for drawing cairo surfaces onto a
gl-using window. This disables e.g. texture-from-pixmap on X11.
software-draw:
Enables both the above.
This was unnecessarily creating a framebuffer in the texture case,
and it was not properly setting up a framebuffer with the texture
as source in the software fallback w/ texture source case.
