mirror of
https://github.com/brl/mutter.git
synced 2024-11-22 08:00:42 -05:00
Read-only mirror of https://gitlab.gnome.org/GNOME/mutter
8e12e40da9
Cogl has a different origin for texture coordinates than OpenGL so that the results of rendering to a texture should leave the top of the image at the texture coordinate 0,0 rather than the bottom. When a GLES2 context is used to render to a Cogl texture via a CoglOffscreen we don't really want the application to have to be aware of the mismatch and flip the texture coordinates. To get that to work, this patch now tracks all of the programs that the application generates using the context and sneaks in an extra vertex shader with an alternative main function. This main function multiplies the final calculated gl_Position by a vector uniform which we can use to flip the image. When the application uploads the source code for a vertex shader we now replace any occurrences of the token 'main' with '_c31' and this renamed function gets called from the replacement main function. The token has a weird name so that it will be unlikely to conflict with a variable name in the application's source but it also needs to have the same number of characters as the original token so that it won't affect column numbers in the error reporting. We are also wrapping glGetShaderSource so that we can try to revert the token name. The same goes for the error logs just in case the error report mentions function names. Both places that cause drawing to occur (glDrawElements and glDrawArrays) are now also wrapped so that we can update the uniform value whenever the program is used with a different type of framebuffer from last time. We additionally need to manually track the state for the viewport, the stencil box and the front face because all of these will be affected by whether we are flipping the image or not. Any attempts to change these states will be queued and instead flushed at the last minute before drawing. There are still some known issues with this patch: • glCopyTexImage2D and glCopyTexSubImage2D will do the wrong thing when copying data from a CoglOffscreen. This could be quite fiddly to solve. • Point sprites won't flip correctly. To make this work we would need to flip the gl_PointSprite builtin variable somehow. This is done in the fragment shader not the vertex shader so flipping the calculated gl_Position doesn't help here. • The patch doesn't attempt to flip rendering to framebuffers for textures created within the GLES2 context. This probably makes sense because those textures are likely to be used within the GLES2 context in which case we want to leave the texture coordinates as they are. However, if the texture is shared back out to Cogl with cogl_gles2_texture_2d_new_from_handle then the texture will be upside-down. • The application can discover our secret uniform that we added via glGetActiveUniform. It might be worth trying to disguise this by wrapping that function although that could be quite fiddly. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d589bf19e51f22c3241b2a18db10f22131ac126a) |
||
|---|---|---|
| build | ||
| cogl | ||
| cogl-gles2 | ||
| cogl-pango | ||
| doc | ||
| examples | ||
| po | ||
| tests | ||
| .gitignore | ||
| .vimrc | ||
| autogen.sh | ||
| ChangeLog | ||
| cogl.doap | ||
| config-custom.h | ||
| config.h.win32.in | ||
| configure.ac | ||
| COPYING | ||
| Makefile.am | ||
| NEWS | ||
| README.in | ||
README for Cogl @COGL_1_VERSION@
===============================================================================
Note: This file is delimited with -- markers so it is possible to split
sections out for other purposes, such as for release notes.
--
DESCRIPTION
-------------------------------------------------------------------------------
Cogl is a small open source library for using 3D graphics hardware for
rendering. The API departs from the flat state machine style of OpenGL and is
designed to make it easy to write orthogonal components that can render without
stepping on each others toes.
As well as aiming for a nice API, we think having a single library as opposed
to an API specification like OpenGL has a few advantages too; like being
able to paper over the inconsistencies/bugs of different OpenGL
implementations in a centralized place, not to mention the myriad of OpenGL
extensions. It also means we are in a better position to provide utility
APIs that help software developers since they only need to be implemented
once and there is no risk of inconsistency between implementations.
Having other backends, besides OpenGL, such as drm, Gallium or D3D are
options we are interested in for the future.
--
REQUIREMENTS
-------------------------------------------------------------------------------
Cogl currently only requires:
• GLib ≥ @GLIB_REQ_VERSION@
• OpenGL ≥ 1.3 (or 1.2 + multitexturing), or OpenGL ES 2.0 (or 1.1)
• GLX, AGL, WGL or an EGL implementation
Cogl also has optional dependencies:
• GDK-Pixbuf ≥ @GDK_PIXBUF_REQ_VERSION@
- for image loading
• Cairo ≥ @CAIRO_REQ_VERSION@
- for debugging texture atlasing (debug builds only)
The optional Cogl Pango library requires:
• Cairo ≥ @CAIRO_REQ_VERSION@
• PangoCairo ≥ @PANGOCAIRO_REQ_VERSION@
On X11, Cogl depends on the following extensions
• XComposite ≥ @XCOMPOSITE_REQ_VERSION@
• XDamage
• XExt
• XFixes ≥ @XFIXES_REQ_VERSION@
When running with OpenGL, Cogl requires at least version 1.3
or 1.2 with the multitexturing extension. However to build Cogl
you will need the latest GL headers which can be obtained from:
http://www.khronos.org
If you are building the API reference you will also need:
• GTK-Doc ≥ @GTK_DOC_REQ_VERSION@
If you are building the additional documentation you will also need:
• xsltproc
• jw (optional, for generating PDFs)
If you are building the Introspection data you will also need:
• GObject-Introspection ≥ @GI_REQ_VERSION@
GObject-Introspection is available from:
git://git.gnome.org/gobject-introspection
If you want support for profiling Cogl you will also need:
• UProf ≥ @UPROF_REQ_VERSION@
UProf is available from:
git://github.com/rib/UProf.git
--
DOCUMENTATION
-------------------------------------------------------------------------------
The API references for the latest stable release are available at:
http://docs.clutter-project.org/docs/cogl/stable/
The experimental 2.0 API can be found here:
http://docs.clutter-project.org/docs/cogl-2.0-experimental/stable/
Note: The confusing "stable" at the end refers to the overall Cogl release
status, not the documentation specifically.
--
LICENSE
-------------------------------------------------------------------------------
Most of Cogl is licensed under the terms of the GNU Lesser General Public
License, version 2.1 or (at your option) later. Some files are licensed under
more permissive licenses MIT or BSD style licenses though so please see
individual files for details.
--
BUILDING AND INSTALLATION
-------------------------------------------------------------------------------
Please refer to the INSTALL document.
--
BUGS
-------------------------------------------------------------------------------
Please report bugs here:
http://bugzilla.gnome.org/enter_bug.cgi?product=cogl
You will need a Bugzilla account.
Please include the following in bug reports:
• what system you're running Cogl on;
• which version of Cogl you are using;
• which version of GLib and OpenGL (or OpenGL ES) you are using;
• which video card and which drivers you are using, including output of
glxinfo and xdpyinfo (if applicable);
• how to reproduce the bug.
If you cannot reproduce the bug with one of the tests that come with
Cogl's source code, it can help a lot to include a small test case
displaying the bad behaviour.
If the bug exposes a crash, the exact text printed out and a stack trace
obtained using gdb are greatly appreciated.
--
CONTRIBUTING
-------------------------------------------------------------------------------
The CODING_STYLE file describes the coding style we use throughout Cogl,
please try your best to conform to this style because the consistency
really helps keep the code maintainable.
We can accept contributions in several ways:
• Either as patches attached to bugs on bugzilla
- For this you may be interested in using git-bz.
See http://git.fishsoup.net/man/git-bz.html for details
• You can email us patches
- For this we recommend using git-send-email
• You can create a remote branch and ask us to pull from that for more
substantial changes.
- For this we recommend using github.
Ideally standalone patches should be created using git format-patch since
that makes it easiest to import the patch with a commit message into a
git repository.