Commit Graph

40 Commits

Author SHA1 Message Date
Matthias Clasen
fbbb3d1816 Fix some clang warnings
It complains about double const, and it is right.
2015-03-22 14:40:57 -04:00
Emmanuele Bassi
03f5d5a5e4 gl: Put shaders in static storage
We are not changing the shader code.

The compiler will hopefully put them in the .rodata section.
2015-02-10 03:33:02 +00:00
Niels Nesse
50187ae86d gdkgl should use shader version 1.50
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
2015-02-10 03:30:09 +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
395125bcfb gl: Do not use the extension API for core GL
Since we are using a Core GL profile, we need to drop the
extension-based API.

https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 19:10:30 +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
Alexander Larsson
a1a01983f7 gdk: Fix scissoring with scaled windows
Make sure the window scale is always taken into acount when setting up
the scissor regions.
2014-12-15 22:31:48 +01:00
Alexander Larsson
2693496b56 gdk_gl_texture_from_surface - fix software fallback
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.
2014-12-15 21:57:02 +01:00
Alexander Larsson
4a4125bcfc gdk_cairo_draw_from_gl - fix drawing with alpha on window scale > 1
The scissoring needs to take into account the window scale.
2014-12-15 21:57:02 +01:00
Marco Trevisan (Treviño)
af2ac29faf gdkgl: pass the correct number of quads to gdk_gl_texture_quads
And call it only if that's the case
2014-12-02 14:59:47 +01:00
Chun-wei Fan
16e863ce65 gdkgl.c: Avoid GCCism in Pointer Arithmetic
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
2014-11-24 22:57:25 +08:00
Jasper St. Pierre
c01e37a9a5 gdkgl: Texture quads in one giant draw call
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.
2014-11-22 10:34:47 -08:00
Jasper St. Pierre
6ffba866a6 gdkgl: Use one VBO for both position and uv attributes 2014-11-22 10:17:43 -08:00
Jasper St. Pierre
37ad6e1147 gdkgl: Texture many quads at once for performance reasons
This isn't fully performant yet. To be fully performant, we'd need to
do everything in one giant buffer.
2014-11-22 10:13:58 -08:00
Jasper St. Pierre
37697f1817 gdkgl: Use a GdkTexturedQuad struct to paint quads
We'll soon have a new function that paints multiple quads.
2014-11-22 09:40:10 -08:00
Jasper St. Pierre
28846536cb gdkgl: Clean up program-manipulating code
Abstract the program ID and locations into a "program struct" which
we then use.
2014-11-22 09:29:27 -08:00
Alexander Larsson
442adf6359 GL: Fix typo in gdk_gl_texture_from_surface
Got a sign wrong in commit 800c712738
2014-11-20 15:37:40 +01:00
Alexander Larsson
800c712738 GL: Fix GL Y coordinate flipping to use unscaled window height
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
2014-11-20 12:38:04 +01:00
Chun-wei Fan
61286d5927 gdk/gdkgl.c: Fix Typo
The extra ';' actually broke builds on C89 compilers...
2014-11-14 17:26:29 +08:00
Javier Jardón
710f332082 configure.ac: Depend on cairo 1.14.0
This is needed for cairo_set_device_scale()
2014-11-10 15:12:17 +00: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
Jasper St. Pierre
22ad7b7782 gdkgl: Make some helper functions static 2014-11-06 13:48:20 -08:00
Alexander Larsson
61eabc4778 gdk_gl_texture_from_surface: Enable scissor test 2014-11-06 20:37:10 +01:00
Alexander Larsson
56631d02bd gdk_gl_texture_quad: Fix handling of window scales 2014-11-06 19:33:58 +01:00
Alexander Larsson
5f9e6ec2dc GdkGL: Fix up GL_ARB_texture_rectangle support
This broke when gdk_gl_texture_quad moved to shaders. We need
a specialized shader for the rectangle case.
2014-11-06 12:24:43 +01:00
Alexander Larsson
90a5fa80af Add GDK_GL env var and GdkGLFlags
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.
2014-11-06 12:24:43 +01:00
Alexander Larsson
7fde5213b0 gdk_cairo_draw_from_gl: Remove useless call
The glFramebufferTexture2DEXT call makes no sense here, we're
not using the texture as a framebuffer, just as a normal
texture source.
2014-11-06 12:24:43 +01:00
Alexander Larsson
e417b18373 gdk_gl_texture_quad: Use shaders to texture things
This is the modern way OpenGL works, and using it will let us
switch to a core context for the paint context, and work on
OpenGL ES 2.0.
2014-11-06 12:24:43 +01:00
Alexander Larsson
c78e7e7f17 GdkGL: Rename "context" to "paint_context" to clarify things a bit 2014-11-06 12:24:43 +01:00
Alexander Larsson
aaa335b9e8 gdk_cairo_draw_from_gl: Document that this changes the current context 2014-11-06 12:24:43 +01:00
Alexander Larsson
10a44e8f7a Add gdk_gl_texture_quad() helper
Right now this just centralizes the glBegin/glEnd code, but
this will be replaced with buffer objects later.
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
e4bf60224b GdkGL: Fix and clean up gdk_cairo_draw_from_gl()
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.
2014-11-05 09:54:05 +01:00
Alexander Larsson
398697eb2f Clarify docs for gdk_cairo_draw_from_gl 2014-10-30 12:43:03 +01:00
Alexander Larsson
f7b1ba0943 opengl: Use GL_TEXTURE_2D rather than GL_TEXTURE_RECTANGLE_ARB when possible
This is more standard, and most driver support non-power-of-2 TEXTURE_2D
these days. We fall back for ancient drivers.
2014-10-27 21:17:08 +01:00
Matthias Clasen
706a7064a0 Trivial formatting fixes 2014-10-13 10:43:32 -04:00
Matthias Clasen
a74c5a1f39 Correct copyright year 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
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