Commit Graph

86 Commits

Author SHA1 Message Date
Timm Bäder
ec2062498f glcontext: Fix buffer age comparison
The old code had a dead >=3 branch, causing flickering.
2017-03-21 19:04:58 +01:00
Benjamin Otte
cd2b898353 wayland: Sync attributes also when drawing with GL
Probably syncing attributes shouldn't happen when drawing in the first
place, but what do I know about Wayland. ¯\_(ツ)_/¯
2016-12-06 18:02:11 +01:00
Benjamin Otte
8915be00d1 gdkgl: Add gdk_gl_context_get_damage()
This is a way to query the damaged area of the backbuffer.

The GL renderer uses this to compute the extents of that damage region
(computed via buffer age) and use them to minimize the area to redraw.

This changes the semantics of GL rendering to "When calling
gdk_window_begin_frame() with a GL context, the area by
gdk_gl_context_get_damage() needs to be redrawn and every other pixel of
the backbuffer is guaranteed to be correct.
After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer
must be correct.

We can always glXBufferSwap() now because of this.
2016-12-05 15:02:47 +01:00
Benjamin Otte
ca78f5d3cb gdk: Make gdk_window_begin_draw_frame() take a draw context
... instead of a gl context.

This requires some refactoring in the way we mark the shared context as
drawing: We now call begin_frame/end_frame() on it and ignore the call
on the main context.
Unfortunately we need to do this check in all vfuncs, which sucks. But I
haven't found a better way.
2016-12-05 15:02:47 +01:00
Benjamin Otte
725a7236c0 gdk: Turn GdkGLContext into a GdkDrawContext 2016-12-05 15:02:47 +01:00
Benjamin Otte
e87b472143 glcontext: Make begin/end_draw() paired
This way, we can query the GL context's state via
gdk_gl_context_is_drawing().

Use this function to make GL contexts as attached and grant them access
to the front/backbuffer for rendering.

All of this is still unused because GL drawing is still disabled.
2016-12-05 15:02:47 +01:00
Benjamin Otte
182d18bcd1 gdk: Large GL refactoring
No visible changes as GL rendering is disabled at the moment.

What was done:

1. Move window->invalidate_for_new_frame to glcontext->begin_frame
This moves the code to where it is used (the GLContext) and prepares it
for being called where it is used when actually beginning to draw the
frame.

2. Get rid of buffer-age usage
We want to let the application render directly to the backbuffer.
Because of that, we cannot make any assumptions about the contents the
application renders outside the clip area.
In particular GskGLRenderer renders random stuff there but not actual
contents.

3. Pass the actual GL context
Previously, we passed the shared context to end_frame, now we pass the
actual GL context that the application uses for rendering. This is so
that the vfuncs could prepare the actual contexts for rendering (they
don't currently).

4. Simplify the code
The previous code set up the final drawing method in begin_frame.
Instead, we now just ensure the clip area is something we can render
and decide on the actual method in end_frame.
This is both more robust (we can change the clip area in between if we
want to) and less code.
2016-12-05 15:02:47 +01:00
Benjamin Otte
f420dc7456 API: gdk: Remove gdk_window_get_visual()
With it, remove window->visual.
2016-10-28 05:22:49 +02:00
Adam Jackson
434ce02ebe Use eglGetPlatformDisplay{,EXT} if available
Calling eglGetDisplay forces libEGL to guess what kind of pointer you
passed it. Different EGL libraries will do different things here, and in
particular glvnd will do something different than Mesa. Since we do have
an API that allows us to explicitly type the display, use it.

The explicit call to eglGetProcAddress is working around a bug in
libepoxy 1.3, which does not understand the EGL concept of client
extensions. Since it does not, the normal epoxy resolver for
eglGetPlatformDisplayEXT would not find any provider for that entry
point, and crash when you attempted to call it.

Signed-off-by: Adam Jackson <ajax@redhat.com>

https://bugzilla.gnome.org/show_bug.cgi?id=772415
2016-10-10 14:17:09 -04:00
Adam Jackson
3b11575f0b Fix some EGLDisplay * abuse
EGLDisplays are already opaque pointers, and eglGetDisplay returns an
EGLDisplay not a pointer to one.

Signed-off-by: Adam Jackson <ajax@redhat.com>

https://bugzilla.gnome.org/show_bug.cgi?id=772415
2016-10-10 14:17:09 -04:00
Matthias Clasen
88248e34b1 Remove an outdated comment
It described as TODO what the code right below it already does.
2016-08-19 23:24:08 -04:00
Emmanuele Bassi
74f4e6e046 wayland: Bind the appropriate OpenGL API
If we want to use OpenGL ES with EGL then we need to bind the API before
creating the EGL context.
2016-04-25 12:29:37 +01:00
Emmanuele Bassi
7d1da94455 wayland: Add debugging notes for EGL context creation 2016-04-25 12:29:37 +01:00
Emmanuele Bassi
d40778f728 wayland: Honour GDK_GL=gles on context creation 2016-04-25 12:29:37 +01:00
Emmanuele Bassi
2849f2fc9a wayland: Implement asking for a GLES context
Wayland uses EGL, which allows us to ask for a GLES context.

https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-25 12:29:37 +01:00
Matthias Clasen
29c1263c4b wayland: 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
f10c0da36c wayland: Allow falling back to compatibility EGL contexts
If the shared context is in legacy mode, or if the creation of a core
profile context failed, we fall back to an EGL context in compatibility
mode.

Since we're relying on a fairly new EGL implementation for Wayland, we
don't fall back to the older EGL API, and instead we always require the
EGL_KHR_create_context extension.

https://bugzilla.gnome.org/show_bug.cgi?id=756142
2015-10-07 16:21:57 +01:00
Matthias Clasen
94c5d691df wayland: Formatting fixes 2015-02-28 00:02:30 -05: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
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
2d9081d117 wayland/gl: Ensure we use the 3.2 core profile
Emit an error if the profile is different.

https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 19:10:30 +00:00
Emmanuele Bassi
f7497daee9 Switch GDK_GL_PROFILE_DEFAULT to mean 3_2_CORE
Instead of LEGACY.

https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 19:10:30 +00:00
Emmanuele Bassi
42a895e85e wayland/gl: Use the GdkGLContext options
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
Alexander Larsson
cf94da2ca1 GdkGLContext: Remove unused update vfunc
The update virtual function for GdkGLContext is unused and is a
leftover from a previous GL approach. Just remove it.

https://bugzilla.gnome.org/show_bug.cgi?id=739750
2014-11-20 12:38:04 +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
0814cd9f8b GdkGlContextWayland: Don't require specific bit depths
This just means we may fail to get a gl context, we just require
*some* color depth.
2014-10-28 18:30:09 +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
6440263ef3 GL: Follow naming conventions
All the GDK type defines are GDK_TYPE_..., so follow this
pattern for the GLContext subclasses as well.
2014-10-21 23:48:12 -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
7eae4985e8 wayland: Add OpenGL support
This uses EGL to implement GdkGLContext for wayland.
2014-10-13 10:43:31 -04:00