summaryrefslogtreecommitdiff
path: root/gdk/gdkglcontext.c
Commit message (Collapse)AuthorAgeFilesLines
* Fixed OpenGL extension detection for extensions promoted to OpenGL core.David Hogan2020-02-141-3/+3
| | | | | | For a given OpenGL context, macOS in particular does not support enumeration / detection of OpenGL features that have been promoted to core OpenGL functionality. It is possible other drivers are the same. This change assumes support for GL_ARB_texture_non_power_of_two with OpenGL 2.0+, GL_ARB_texture_rectangle with OpenGL 3.1+ and GL_EXT_framebuffer_blit with OpenGL 3.0+. I failed to find definitive information on whether GL_GREMEDY_frame_terminator has been promoted to OpenGL core, or whether GL_ANGLE_framebuffer_blit or GL_EXT_unpack_subimage have been promoted to core in OpenGL ES. This change results in a significant GtkGLArea performance boost on macOS. Closes #2428
* Add a EGL renderer (via ANGLE) for WindowsChun-wei Fan2018-06-281-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* doc: Replace uses of #NULL with %NULLDaniel Boles2017-11-221-1/+1
|
* GdkGLContext: chain finalize handlerMassimo Valentini2016-11-101-0/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=773979
* gl: Set legacy bit depending on OpenGL versionEmmanuele Bassi2016-10-231-1/+8
| | | | | | | | | | | | GDK defaults to asking for an OpenGL 3.2 Core Profile, but if we get a legacy profile from the underlying windowing system, the OpenGL version will be fixed to 3.0. If that happens, we need to set the legacy bit on the GdkGLContext, since that bit will be used to determine the version and type of GLSL shaders that will be used by application and toolkit code alike. (cherry picked from commit 31c05771e957f2f54fb197a391b63e6ef3394a26) Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
* gl: Check whether use_es is positiveEmmanuele Bassi2016-10-231-2/+2
| | | | | | | | | Now that the use_es field is an int with a possible negative value, we cannot use it its truth value directly; we need to check if it's a positive value, instead. (cherry picked from commit 8e85f55240d4e3a2191c7945c7e76a6f20a4d32d) Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
* gdk/gl: Allow autodetection for GL/GLESEmmanuele Bassi2016-10-211-5/+21
| | | | | | | If the GdkGLContext was not explicitly instructed to use or not GLES, we can detect whether the underlying API is going to be desktop GL or GLES. https://bugzilla.gnome.org/show_bug.cgi?id=773180
* gdk: Don't second-guess whether a context is GLESAdam Jackson2016-10-211-1/+0
| | | | | | | | | We've already set ->use_es correctly at context creation time, all this can possibly do is change our mind about what kind of GL we're using. Signed-off-by: Adam Jackson <ajax@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=773180
* Add some missing (nullable) annotationsRico Tzschichholz2016-09-221-4/+4
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=771826
* gl: Add a realize() fallbackEmmanuele Bassi2016-05-231-0/+12
| | | | | | Calling gdk_gl_context_realize() should always result in a valid result, so we need to provide a default implementation, to avoid a call to a NULL function pointer.
* gdk/gdkglcontext.c: Avoid a GCCismChun-wei Fan2016-04-261-2/+2
| | | | | Pointer arithmetic on GLvoid* (a void*) is a GCCism, so cast it to an unsigned char*, which is the type cairo_image_surface_get_data() returns.
* docs: Clarify the platform-dependency of GdkGLContext:use-esEmmanuele Bassi2016-04-251-4/+5
| | | | Not all platforms allow creating an OpenGL ES context.
* gl: Add fallback for missing subimage unpackingEmmanuele Bassi2016-04-251-5/+23
| | | | | For GLES 2.0 platforms with the subimage unpacking extension we need to upload one row of the image surface at a time.
* gl: Use the appropriate format on GLESEmmanuele Bassi2016-04-251-3/+11
| | | | | | When uploading a Cairo image surface to a GL texture we cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV on OpenGL ES, as they do not exist in the core spec.
* gl: Add more OpenGL ES checksEmmanuele Bassi2016-04-251-21/+92
| | | | | Check for the appropriate extensions depending on which type of API we're using.
* gl: Relay use-es from context to paint dataEmmanuele Bassi2016-04-251-0/+1
| | | | | | This way we can select the appropriate API or the appropriate shaders. https://bugzilla.gnome.org/show_bug.cgi?id=743746
* gl: Add 'use-es' flagEmmanuele Bassi2016-04-251-5/+41
| | | | | | | | | | | | | On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
* gdk: Don't use g_print for debug outputMatthias Clasen2016-02-281-13/+13
| | | | | | The g_print documentation explicitly says not to do this, since g_print is meant to be redirected by applications. Instead use g_message for logging that can be triggered via GTK_DEBUG.
* docs: Improve description of gdk_gl_context_is_legacy()Emmanuele Bassi2015-10-071-1/+14
| | | | | | Explain why this function is available, and why you may need it. https://bugzilla.gnome.org/show_bug.cgi?id=756142
* gl: Store the legacy bit in the GL program dataEmmanuele Bassi2015-10-071-1/+4
| | | | | | We need to know if we're using a legacy GL context in various places. https://bugzilla.gnome.org/show_bug.cgi?id=756142
* gdk: Allow querying if a GL context is in legacy modeEmmanuele Bassi2015-10-071-0/+33
| | | | | | | | | | | | | | | | | | | | We want to have the ability to fall back to legacy GL contexts when creating them. In order to do so, we need to store the legacy bit on the GdkGLContext, as well as being able to query it. Setting the legacy bit from outside GDK is not possible; we cannot create GL contexts in 3.2 core profile *and* compatibility modes at the same time, and if we allowed users to select the legacy mode themselves, it would break the creation of the GdkWindow's paint GL context. What we do allow is falling back to legacy GL context if the platform does not support 3.2 core profiles — for instance, on older GPUs or inside virtualized environments. We are also going to use the legacy bit internally, to choose which GL API we can use when drawing GL content. https://bugzilla.gnome.org/show_bug.cgi?id=756142
* GdkGLContext little fix to property names and descriptions.Daniel Hams2015-07-191-3/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=752502
* gl: Warn the user if they request a GL context version less than 3.2Niels Nesse2015-03-061-7/+10
| | | | | | | | | If the user requests a version less than 3.2 the version is forced to 3.2. Previous checking code have an inconsistent behavior depending on which minor version number was specified. This is avoided now by temporarily converting the major/minor pair into a single integer. https://bugzilla.gnome.org/show_bug.cgi?id=744288
* Remove GdkGLProfileEmmanuele Bassi2015-02-121-75/+0
| | | | | | | | | | | | | | | 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
* gl: Add gdk_gl_context_get_version()Emmanuele Bassi2015-02-121-1/+34
| | | | | | Store the OpenGL version when we first do the extensions check; this allows client code to check the available GL version without requiring a call to gdk_gl_context_make_current() and epoxy_gl_version().
* gl: Drop profile for gdk_window_create_gl_context()Emmanuele Bassi2015-02-121-3/+31
| | | | | | 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.
* gl: Fix the required version setterEmmanuele Bassi2015-02-101-1/+14
| | | | | | | We don't allow a version tuple to be lower than (3, 2), but we should allow versions above that. https://bugzilla.gnome.org/show_bug.cgi?id=744212
* gl: Drop GdkGLContextClass.upload_texture()Emmanuele Bassi2015-02-091-5/+1
| | | | It's unnecessary to allow per-backend overrides.
* gl: Clean up the required version accessorsEmmanuele Bassi2015-02-091-28/+17
| | | | | | We can simplify the code, since we only have core GL profiles in GDK. https://bugzilla.gnome.org/show_bug.cgi?id=741946
* docs: We do not support non-core GL profilesEmmanuele Bassi2015-02-091-12/+14
| | | | | | | No need to mention that some API only works on core GL profiles in the GdkGLContext docs. https://bugzilla.gnome.org/show_bug.cgi?id=741946
* gl: Clean up pre-requisite checks for GdkGLContext settersEmmanuele Bassi2015-02-091-1/+3
| | | | | | We don't support non-core profiles. https://bugzilla.gnome.org/show_bug.cgi?id=741946
* gl: Add more debugging notesEmmanuele Bassi2015-02-091-0/+13
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=741946
* gl: Drop OpenGL legacy profileEmmanuele Bassi2015-02-091-11/+1
| | | | | | | | | | | | | We simply don't want to care about legacy OpenGL. All supported platforms also have support for OpenGL ≥ 3.2; it would complicate the internal code; and would force us to use legacy GL contexts internally if the first context created by the user is a legacy GL context, and disable creation of core-3.2 contexts after that. We will need to fix all our code examples to use the Core 3.2 profile. https://bugzilla.gnome.org/show_bug.cgi?id=741946
* gl: Move getters for context options to the public APIEmmanuele Bassi2015-02-091-3/+13
| | | | | | They can be useful for third party code as well. https://bugzilla.gnome.org/show_bug.cgi?id=741946
* gl: Add context optionsEmmanuele Bassi2015-02-091-0/+185
| | | | | | | | | | | | | | | | | | | | 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.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
* GL: Split GL context creation in two phasesEmmanuele Bassi2015-02-091-5/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix core context creation in GdkGLContextNiels Nesse2015-01-281-1/+1
| | | | | | | | | | | | | | | - 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
* gdkgl: Use vfunc For Uploading TexturesChun-wei Fan2014-12-171-0/+20
| | | | | | | | | | | | 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
* Move GDK GL flags accessors to the private vtableEmmanuele Bassi2014-11-081-0/+1
| | | | | | This allows us to use the GDK_PRIVATE_CALL macro inside gtk. https://bugzilla.gnome.org/show_bug.cgi?id=739781
* Export API to set GL flagsMatthias Clasen2014-11-061-2/+31
| | | | This will be used in the inspector.
* GdkX11GLContext: Use bitblit for swap if no buffer age supportAlexander Larsson2014-11-061-0/+10
| | | | | | | | | If buffer age is undefined and the updated area is not the whole window then we use bit-blits instead of swap-buffers to end the frame. This allows us to not repaint the entire window unnecessarily if buffer_age is not supported, like e.g. with DRI2.
* Add gdk_gl_context_has_framebuffer_blit()Alexander Larsson2014-11-061-0/+11
| | | | This checks if the context supports GL_EXT_framebuffer_blit
* Add support for GDK_GL=texture-rectanglesAlexander Larsson2014-11-061-1/+3
| | | | This allows us to test our support for GL_ARB_texture_rectangle
* gdkgl: Don't constantly re-create the tmp framebufferAlexander Larsson2014-11-061-0/+23
|
* GdkGLContext: Add display propertyAlexander Larsson2014-11-031-2/+59
| | | | | | | We need to use this in the code path where we make the context non-current during destroy, because at that point the window could be destroyed and gdk_window_get_display() would return NULL.
* Add GdkGLContext::profileAlexander Larsson2014-10-301-0/+47
|
* Remove GdkGLContext::visualAlexander Larsson2014-10-301-53/+0
| | | | | | | | | | | This is not really needed. The gl context is totally tied to the window it is created from by virtue of sharing the context with the paint context of that window and that context always has the visual of the window (which we already can get). Also, all user visible contexts are essentially offscreen contexts, so a visual doesn't make sense for them. They only use FBOs which have whatever format that the users sets up.
* GdkGLContext: Track shared contextAlexander Larsson2014-10-301-0/+52
| | | | | This allows us to read it back, but primarily it ensures the shared context wrapper stays alive as long as the context.
* GdkGLContext: Change the way we track the current contextAlexander Larsson2014-10-301-8/+29
| | | | | | | To properly support multithreaded use we use a global GPrivate to track the current context. Since we also don't need to track the current context on the display we move gdk_display_destroy_gl_context to GdkGLContext::discard.
* gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARBAlexander Larsson2014-10-271-0/+36
|
View Lorry Controller Status