Commit Graph

100 Commits

Author SHA1 Message Date
Emmanuele Bassi
b878ec7f2f gdk/gl: Allow autodetection for GL/GLES
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
2016-10-21 11:39:24 -04:00
Adam Jackson
627867863f gdk: Don't second-guess whether a context is GLES
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
2016-10-21 11:39:24 -04:00
Rico Tzschichholz
a3f1596069 Add some missing (nullable) annotations
https://bugzilla.gnome.org/show_bug.cgi?id=771826
2016-09-22 14:02:07 +02:00
Emmanuele Bassi
fe684078f9 gl: Add a realize() fallback
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.
2016-05-23 08:34:17 +01:00
Chun-wei Fan
7700243bd4 gdk/gdkglcontext.c: Avoid a GCCism
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.
2016-04-26 20:29:23 +08:00
Emmanuele Bassi
79a7e881b1 docs: Clarify the platform-dependency of GdkGLContext:use-es
Not all platforms allow creating an OpenGL ES context.
2016-04-25 14:35:02 +01:00
Emmanuele Bassi
1379b4b175 gl: Add fallback for missing subimage unpacking
For GLES 2.0 platforms with the subimage unpacking extension we need to
upload one row of the image surface at a time.
2016-04-25 14:33:35 +01:00
Emmanuele Bassi
5b03cf175a gl: Use the appropriate format on GLES
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.
2016-04-25 12:29:36 +01:00
Emmanuele Bassi
1620b7bda7 gl: Add more OpenGL ES checks
Check for the appropriate extensions depending on which type of API
we're using.
2016-04-25 12:29:36 +01:00
Emmanuele Bassi
d7b5ea89eb gl: Relay use-es from context to paint data
This way we can select the appropriate API or the appropriate shaders.

https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-25 12:29:36 +01:00
Emmanuele Bassi
e1cecd243a gl: Add 'use-es' flag
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
2016-04-25 12:29:36 +01:00
Matthias Clasen
2801f3c843 gdk: Don't use g_print for debug output
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.
2016-02-28 21:40:23 -05:00
Emmanuele Bassi
59d02afec0 docs: Improve description of gdk_gl_context_is_legacy()
Explain why this function is available, and why you may need it.

https://bugzilla.gnome.org/show_bug.cgi?id=756142
2015-10-07 16:21:57 +01:00
Emmanuele Bassi
24230ca783 gl: Store the legacy bit in the GL program data
We need to know if we're using a legacy GL context in various places.

https://bugzilla.gnome.org/show_bug.cgi?id=756142
2015-10-07 16:21:57 +01:00
Emmanuele Bassi
2dfca143bb gdk: Allow querying if a GL context is in legacy mode
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
2015-10-07 16:21:57 +01:00
Daniel Hams
e0f0197d0c GdkGLContext little fix to property names and descriptions.
https://bugzilla.gnome.org/show_bug.cgi?id=752502
2015-07-19 14:14:25 -04:00
Niels Nesse
b87715973f gl: Warn the user if they request a GL context version less than 3.2
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
2015-03-06 14:02:55 +01:00
Emmanuele Bassi
d066e7541e Remove GdkGLProfile
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
2015-02-12 17:51:31 +00:00
Emmanuele Bassi
390a42fa60 gl: Add gdk_gl_context_get_version()
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().
2015-02-12 14:29:44 +00:00
Emmanuele Bassi
022724aa69 gl: Drop profile for gdk_window_create_gl_context()
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.
2015-02-12 12:34:28 +00:00
Emmanuele Bassi
5666522ab3 gl: Fix the required version setter
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
2015-02-10 10:16:53 +00:00
Emmanuele Bassi
843475bd2e gl: Drop GdkGLContextClass.upload_texture()
It's unnecessary to allow per-backend overrides.
2015-02-09 19:10:31 +00:00
Emmanuele Bassi
2d35053d97 gl: Clean up the required version accessors
We can simplify the code, since we only have core GL profiles in GDK.

https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 19:10:30 +00:00
Emmanuele Bassi
4ad887f4bf docs: We do not support non-core GL profiles
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
2015-02-09 19:10:30 +00:00
Emmanuele Bassi
601c49ef39 gl: Clean up pre-requisite checks for GdkGLContext setters
We don't support non-core profiles.

https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 19:10:30 +00:00
Emmanuele Bassi
1d3cc65e89 gl: Add more debugging notes
https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 19:10:30 +00:00
Emmanuele Bassi
4b8b3b431b gl: Drop OpenGL legacy profile
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
2015-02-09 19:10:30 +00:00
Emmanuele Bassi
6aaa6c337b gl: Move getters for context options to the public API
They can be useful for third party code as well.

https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 19:10:30 +00:00
Emmanuele Bassi
fa90052299 gl: Add context options
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
2015-02-09 19:10:05 +00:00
Emmanuele Bassi
22e6f37c9c GL: Split GL context creation in two phases
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
2015-02-09 19:10:04 +00:00
Niels Nesse
27cf0fa34c Fix core context creation in GdkGLContext
- 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
2015-01-28 12:00:30 +00:00
Chun-wei Fan
9fd9f61b00 gdkgl: Use vfunc For Uploading Textures
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
2014-12-17 16:06:25 +08:00
Emmanuele Bassi
585af218a3 Move GDK GL flags accessors to the private vtable
This allows us to use the GDK_PRIVATE_CALL macro inside gtk.

https://bugzilla.gnome.org/show_bug.cgi?id=739781
2014-11-08 00:20:15 -05:00
Matthias Clasen
5d0d1e524e Export API to set GL flags
This will be used in the inspector.
2014-11-06 23:29:16 -05:00
Alexander Larsson
1f3f933edf GdkX11GLContext: Use bitblit for swap if no buffer age support
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.
2014-11-06 12:24:43 +01:00
Alexander Larsson
21189b9f7e Add gdk_gl_context_has_framebuffer_blit()
This checks if the context supports GL_EXT_framebuffer_blit
2014-11-06 12:24:43 +01:00
Alexander Larsson
650c9f3b7e Add support for GDK_GL=texture-rectangles
This allows us to test our support for GL_ARB_texture_rectangle
2014-11-06 12:24:43 +01:00
Alexander Larsson
3c34ca3405 gdkgl: Don't constantly re-create the tmp framebuffer 2014-11-06 12:24:43 +01:00
Alexander Larsson
6fbc439fd7 GdkGLContext: Add display property
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.
2014-11-03 13:20:55 +01:00
Alexander Larsson
0eb2fb01fd Add GdkGLContext::profile 2014-10-30 12:43:03 +01:00
Alexander Larsson
f0ae8da993 Remove GdkGLContext::visual
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.
2014-10-30 12:43:03 +01:00
Alexander Larsson
dbbab0791d GdkGLContext: Track shared context
This allows us to read it back, but primarily it ensures
the shared context wrapper stays alive as long as the context.
2014-10-30 12:43:03 +01:00
Alexander Larsson
fb50015519 GdkGLContext: Change the way we track the current context
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.
2014-10-30 12:43:03 +01:00
Alexander Larsson
72a6459d73 gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB 2014-10-27 21:17:08 +01:00
Alexander Larsson
3013997e23 Rename gdk_gl_context_flush_buffer to gdk_gl_context_end_frame
This makes a lot more sense.
2014-10-27 16:33:37 +01:00
Matthias Clasen
98904b8910 Nitpicky documentation changes 2014-10-13 10:43:32 -04:00
Matthias Clasen
706a7064a0 Trivial formatting fixes 2014-10-13 10:43:32 -04:00
Alexander Larsson
fdeb4f8c16 gl: Make gdk_gl_context_make_current() return void
Its not really reasonable to handle failures to make_current, it
basically only happens if you pass invalid arguments to it, and
thats not something we trap on similar things on the X drawing side.

If GL is not supported that should be handled by the context creation
failing, and anything going wrong after that is essentially a critical
(or an async X error).
2014-10-13 10:43:32 -04:00
Alexander Larsson
236d08c3c5 gl: Make all user GdkGLContexts not attached to any window
We make user facing gl contexts not attached to a surface if possible,
or attached to dummy surfaces. This means nothing can accidentally
read/write to the toplevel back buffer.
2014-10-13 10:43:31 -04:00
Alexander Larsson
038aac6275 gdk: Add support for OpenGL
This adds the new type GdkGLContext that wraps an OpenGL context for a
particular native window. It also adds support for the gdk paint
machinery to use OpenGL to draw everything. As soon as anyone creates
a GL context for a native window we create a "paint context" for that
GdkWindow and switch to using GL for painting it.

This commit contains only an implementation for X11 (using GLX).

The way painting works is that all client gl contexts draw into
offscreen buffers rather than directly to the back buffer, and the
way something gets onto the window is by using gdk_cairo_draw_from_gl()
to draw part of that buffer onto the draw cairo context.

As a fallback (if we're doing redirected drawing or some effect like a
cairo_push_group()) we read back the gl buffer into memory and composite
using cairo. This means that GL rendering works in all cases, including
rendering to a PDF. However, this is not particularly fast.

In the *typical* case, where we're drawing directly to the window in
the regular paint loop we hit the fast path. The fast path uses opengl
to draw the buffer to the window back buffer, either by blitting or
texturing. Then we track the region that was drawn, and when the draw
ends we paint the normal cairo surface to the window (using
texture-from-pixmap in the X11 case, or texture from cairo image
otherwise) in the regions where there is no gl painted.

There are some complexities wrt layering of gl and cairo areas though:
* We track via gdk_window_mark_paint_from_clip() whenever gtk is
  painting over a region we previously rendered with opengl
  (flushed_region). This area (needs_blend_region) is blended
  rather than copied at the end of the frame.
* If we're drawing a gl texture with alpha we first copy the current
  cairo_surface inside the target region to the back buffer before
  we blend over it.

These two operations allow us full stacking of transparent gl and cairo
regions.
2014-10-13 10:43:31 -04:00