This commit introduces some new framebuffer api to be able to
enable texture based depth buffers for a framebuffer (currently
only supported for offscreen framebuffers) and once allocated
to be able to retrieve the depth buffer as a texture for further
usage, say, to implement shadow mapping.
The API works as follow:
* Before the framebuffer is allocated, you can request that a depth
texture is created with
cogl_framebuffer_set_depth_texture_enabled()
* cogl_framebuffer_get_depth_texture() can then be used to grab a
CoglTexture once the framebuffer has been allocated.
The automagic paragraph support of gtk-doc is way too simple to support
things like multi-paragraphs <note>s. Let's trick gtk-doc and make it
generate a valid docbook snippet for cogl-context.
Without this, cogl-context remains absent of the reference
documentation, how sad is this?!
(cherry picked from commit 606b472d91450e3221da6631020f534892e866a9)
We want applications to fully control the lifetime of a CoglContext
without having to worry that internal resources (such as the default
2d,3d and rectangle textures, or any caches we maintain) could result in
circular references that keep the context alive. We also want to avoid
making CoglContext into a special kind of object that isn't ref-counted
or that can't be used with object apis such as
cogl_object_set_user_data. Being able to reliably destroy the context is
important on platforms such as Android where you may be required
bring-up and tear-down a CoglContext numerous times throughout the
applications lifetime. A dissadvantage of this policy is that it is now
possible to leave other object such as framebuffers in an inconsistent
state if the context is unreferenced and destroyed. The documentation
states that all objects that directly or indirectly depend on a context
that has been destroyed will be left in an inconsistent state and must
not be accessed thereafter. Applications (such as Android applications)
that need to cleanly destroy and re-create Cogl resources should make
sure to manually unref these dependant objects before destroying the
context.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 23ce51beba1bb739a224e47614a59327dfbb65af)
Otherwise, X11 identifiers may leak and cause havoc in big applications
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit ed0cdca0eca815543619fe72fbd42d662d53f92d)
This makes it possible to integrate existing GLES2 code with
applications using Cogl as the rendering api.
Currently all GLES2 usage is handled with separate GLES2 contexts to
ensure that GLES2 api usage doesn't interfere with Cogl's own use of
OpenGL[ES]. The api has been designed though so we can provide tighter
integration later.
The api would allow us to support GLES2 virtualized on top of an
OpenGL/GLX driver as well as GLES2 virtualized on the core rendering api
of Cogl itself. Virtualizing the GLES2 support on Cogl will allow us to
take advantage of Cogl debugging facilities as well as let us optimize
the cost of allocating multiple GLES2 contexts and switching between
them which can both be very expensive with many drivers.
As as a side effect of this patch Cogl can also now be used as a
portable window system binding API for GLES2 as an alternative to EGL.
Parts of this patch are based on work done by Tomeu Vizoso
<tomeu.vizoso@collabora.com> who did the first iteration of adding GLES2
API support to Cogl so that WebGL support could be added to
webkit-clutter.
This patch adds a very minimal cogl-gles2-context example that shows how
to create a gles2 context, clear the screen to a random color and also
draw a triangle with the cogl api.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 4bb6eff3dbd50d8fef7d6bdbed55c5aaa70036a8)
The coding style has for a long time said to avoid using redundant glib
data types such as gint or gchar etc because we feel that they make the
code look unnecessarily foreign to developers coming from outside of the
Gnome developer community.
Note: When we tried to find the historical rationale for the types we
just found that they were apparently only added for consistent syntax
highlighting which didn't seem that compelling.
Up until now we have been continuing to use some of the platform
specific type such as gint{8,16,32,64} and gsize but this patch switches
us over to using the standard c99 equivalents instead so we can further
ensure that our code looks familiar to the widest range of C developers
who might potentially contribute to Cogl.
So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this
switches all Cogl code to instead use the int{8,16,32,64}_t and
uint{8,16,32,64}_t c99 types instead.
Instead of gsize we now use size_t
For now we are not going to use the c99 _Bool type and instead we have
introduced a new CoglBool type to use instead of gboolean.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
Removing CoglHandle has been an on going goal for quite a long time now
and finally this patch removes the last remaining uses of the CoglHandle
type and the cogl_handle_ apis.
Since the big remaining users of CoglHandle were the cogl_program_ and
cogl_shader_ apis which have replaced with the CoglSnippets api this
patch removes both of these apis.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 6ed3aaf4be21d605a1ed3176b3ea825933f85cf0)
Since the original patch was done after removing deprecated API
this back ported patch doesn't affect deprecated API and so
actually this cherry-pick doesn't remove all remaining use of
CoglHandle as it did for the master branch of Cogl.
The 2.0 API for querying features (cogl_has_feature etc) does not
conflict with the old 1.0 API (cogl_features_available) so we might as
well enable it when the experimental API is requested without
requesting the 2.0-only API.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The idea is that CoglPixelBuffer should just be a buffer that can be
used for pixel data and it has no idea about the details of any images
that are stored in it. This is analogous to CoglAttributeBuffer which
itself does not have any information about the attributes. When you
want to use a pixel buffer you should create a CoglBitmap which points
to a region of the attribute buffer and provides the extra needed
information such as the width, height and format. That way it is also
possible to use a single CoglPixelBuffer with multiple bitmaps.
The changes that are made are:
• cogl_pixel_buffer_new_with_size has been removed and in its place is
cogl_bitmap_new_with_size. This will create a pixel buffer at the
right size and rowstride for the given width/height/format and
immediately create a single CoglBitmap to point into it. The old
function had an out-parameter for the stride of the image but with
the new API this should be queriable from the bitmap (although there
is no function for this yet).
• There is now a public cogl_pixel_buffer_new constructor. This takes
a size in bytes and data pointer similarly to
cogl_attribute_buffer_new.
• cogl_texture_new_from_buffer has been removed. If you want to create
a texture from a pixel buffer you should wrap it up in a bitmap
first. There is already API to create a texture from a bitmap.
This patch also does a bit of header juggling because cogl-context.h
was including cogl-texture.h and cogl-framebuffer.h which were causing
some circular dependencies when cogl-bitmap.h includes cogl-context.h.
These weren't actually needed in cogl-context.h itself but a few other
headers were relying on them being included so this adds the #includes
where necessary.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
So we can get to the point where cogl.h is merely an aggregation of
header includes for the 1.x api this moves all the function prototypes
and type definitions into a cogl-context.h and a new cogl1-context.h.
Ideally no code internally should ever need to include cogl.h as it just
represents the public facing header for accessing the 1.x api which
should only be used by Clutter.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Originally we decided to use #define tricks to rename all experimental
symbols so that they had an _EXP suffix so it would be a bit clearer for
those wanting to check for ABI changes that they shouldn't worry about
these experimental symbols.
We feel now though that the defines are a bit more hassle than they are
really worth, since they are one extra thing to remember when coding,
they make using gdb slightly more awkward since you have to use the real
symbol name to set breakpoints and we already have a mechanism for
declaring symbols as experimental via gtk-doc that can be used by anyone
wanting to check for ABI changes.
Instead of just using a script to remove all the #defines we are going
to go through them manually because we need to make sure the symbols
are marked as unstable via gtk-doc. This patch does a first batch of
define removals and in fact some of the symbols didn't have any
documentation at all so that needed to be added too.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This renames cogl_context_egl_get_egl_context to
cogl_egl_context_get_egl_context to be consistent with other platform
specific APIs.
Signed-off-by: Neil Roberts <neil@linux.intel.com>
For cogl 2.0 we don't want to have a default context. In the meantime
we can simply assume that calling cogl_context_new() implicitly
sets that context as the default context before returning.
Signed-off-by: Neil Roberts <neil@linux.intel.com>
The native window type of the EGL/Android winsys is ANativeWinow*. The
Android NDK gives you a pointer to this ANativeWindow and you just need
to configure that window using the EGLConfig you are choosing when
creating the context.
This means you have to know the ANativeWindow* window before creating
the context. This is solved here by just having a global variable you
can set with cogl_android_set_native_window() before creating the
context. This is a bit ugly though, and it conceptually belongs to the
OnScreen creation to know which ANativeWindow* to use. This would need a
"lazy context creation" mechanism, waiting for the user to create the
OnScreen to initialize the GL context.
Early implementations provided only a GLES/egl.h while Khronos's
implementer guide now states EGL/egl.h is the One. Some implementations
keep a GLES/egl.h wrapper around EGL/egl.h for backward compatibility
while others provide EGL/egl.h only.
Also took the opportunity to factorize a bit this inclusion in
cogl-defines.h.
As was recently done for the GLX window system code, this commit moves
the EGL window system code down from the Clutter backend code into a
Cogl winsys.
Note: currently the cogl/configure.ac is hard coded to only build the GLX
winsys so currently this is only available when building Cogl as part
of Clutter.
This migrates all the GLX window system code down from the Clutter
backend code into a Cogl winsys. Moving OpenGL window system binding
code down from Clutter into Cogl is the biggest blocker to having Cogl
become a standalone 3D graphics library, so this is an important step in
that direction.
This adds a new experimental function (you need to define
COGL_ENABLE_EXPERIMENTAL_API to access it) which takes us towards being
able to have a standalone Cogl API. This is really a minor aesthetic
change for now since all the GL context creation code still lives in
Clutter but it's a step forward none the less.
Since our current designs introduce a CoglDisplay object as something
that would be passed to the context constructor this provides a stub
cogl-display.h with CoglDisplay typedef.
_cogl_context_get_default() which Clutter uses to access the Cogl
context has been modified to use cogl_context_new() to initialize
the default context.
There is one rather nasty hack used in this patch which is that the
implementation of cogl_context_new() has to forcibly make the allocated
context become the default context because currently all the code in
Cogl assumes it can access the context using _COGL_GET_CONTEXT including
code used to initialize the context.
Instead of directly banging GL to migrate textures the atlas now uses
the CoglFramebuffer API. It will use one of four approaches; it can
set up two FBOs and use _cogl_blit_framebuffer to copy between them;
it can use a single target fbo and then render the source texture to
the FBO using a Cogl draw call; it can use a single FBO and call
glCopyTexSubImage2D; or it can fallback to reading all of the texture
data back to system memory and uploading it again with a sub texture
update.
Previously GL calls were used directly because Cogl wasn't able to
create a framebuffer without a stencil and depth buffer. However there
is now an internal version of cogl_offscreen_new_to_texture which
takes a set of flags to disable the two buffers.
The code for blitting has now been moved into a separate file called
cogl-blit.c because it has become quite long and it may be useful
outside of the atlas at some point.
The 4 different methods have a fixed order of preference which is:
* Texture render between two FBOs
* glBlitFramebuffer
* glCopyTexSubImage2D
* glGetTexImage + glTexSubImage2D
Once a method is succesfully used it is tried first for all subsequent
blits. The default default can be overridden by setting the
environment variable COGL_ATLAS_DEFAULT_BLIT_MODE to one of the
following values:
* texture-render
* framebuffer
* copy-tex-sub-image
* get-tex-data
Instead of having a single journal per context, we now have a
CoglJournal object for each CoglFramebuffer. This means we now don't
have to flush the journal when switching/pushing/popping between
different framebuffers so for example a Clutter scene that involves some
ClutterEffect actors that transiently redirect to an FBO can still be
batched.
This also allows us to track state in the journal that relates to the
current frame of its associated framebuffer which we'll need for our
optimization for using the CPU to handle reading a single pixel back
from a framebuffer when we know the whole scene is currently comprised
of simple rectangles in a journal.
In the journal code and when generating the stroke path the vertices
are generated on the fly and stored in a CoglBuffer using
cogl_buffer_map. However cogl_buffer_map is allowed to fail but it
wasn't checking for a NULL return value. In particular on GLES it will
always fail because glMapBuffer is only provided by an extension. This
adds a new pair of internal functions called
_cogl_buffer_{un,}map_for_fill_or_fallback which wrap
cogl_buffer_map. If the map fails then it will instead return a
pointer into a GByteArray attached to the context. When the buffer is
unmapped the array is copied into the buffer using
cogl_buffer_set_data.
Previously Cogl would only ever use one atlas for textures and if it
reached the maximum texture size then all other new textures would get
their own GL texture. This patch makes it so that we create as many
atlases as needed. This should avoid breaking up some batches and it
will be particularly good if we switch to always using multi-texturing
with a default shader that selects between multiple atlases using a
vertex attribute.
Whenever a new atlas is created it is stored in a GSList on the
context. A weak weference is taken on the atlas using
cogl_object_set_user_data so that it can be removed from the list when
the atlas is destroyed. The atlas textures themselves take a reference
to the atlas and this is the only thing that keeps the atlas
alive. This means that once the atlas becomes empty it will
automatically be destroyed.
All of the COGL_NOTEs pertaining to atlases are now prefixed with the
atlas pointer to make it clearer which atlas is changing.
Once the GLES2 wrapper is removed we won't be able to upload the
matrices with the fixed function API any more. The fixed function API
gives a global state for setting the matrix but if a custom shader
uniform is used for the matrices then the state is per
program. _cogl_matrix_stack_flush_to_gl is called in a few places and
it is assumed the current pipeline doesn't need to be flushed before
it is called. To allow these semantics to continue to work, on GLES2
the matrix flush now just stores a reference to the matrix stack in
the CoglContext. A pre_paint virtual is added to the progend which is
called whenever a pipeline is flushed, even if the same pipeline was
flushed already. This gives the GLSL progend a chance to upload the
matrices to the uniforms. The combined modelview/projection matrix is
only calculated if it is used. The generated programs end up never
using the modelview or projection matrix so it usually only has to
upload the combined matrix. When a matrix stack is flushed a reference
is taked to it by the pipeline progend and the age is stored so that
if the same state is used with the same program again then we don't
need to reupload the uniform.
When the GLES2 wrapper is removed we can't use the fixed function API
such as glColorPointer to set the builtin attributes. Instead the GLSL
progend now maintains a cache of attribute locations that are queried
with glGetAttribLocation. The code that previously maintained a cache
of the enabled texture coord arrays has been modified to also cache
the enabled vertex attributes under GLES2. The vertex attribute API is
now the only place that is using this cache so it has been moved into
cogl-vertex-attribute.c
The GLSL vertend is mostly only useful for GLES2. The fixed function
vertend is kept at higher priority than the GLSL vertend so it is
unlikely to be used in any other circumstances.
We were trying to declare and initializing an arbfp program cache for
GLES but since the prototypes for the _hash and _equal functions were
only available for GL this broke the GLES builds. By #ifdefing the code
to conditionally declare/initialize for GL only this should hopefully
fix GLES builds.
This adds a cache (A GHashTable) of ARBfp programs and before ever
starting to code-generate a new program we will always first try and
find an existing program in the cache. This uses _cogl_pipeline_hash and
_cogl_pipeline_equal to hash and compare the keys for the cache.
There is a new COGL_DEBUG=disable-program-caches option that can disable
the cache for debugging purposes.
Before flushing the journal there is now a separate iteration that
will try to determine if the matrix of the clip stack and the matrix
of the rectangle in each entry are on the same plane. If they are it
can completely avoid the clip stack and instead manually modify the
vertex and texture coordinates to implement the clip. The has the
advantage that it won't break up batching if a single clipped
rectangle is used in a scene.
The software clip is only used if there is no user program and no
texture matrices. There is a threshold to the size of the batch where
it is assumed that it is worth the cost to break up a batch and
program the GPU to do the clipping. Currently this is set to 8
although this figure is plucked out of thin air.
To check whether the two matrices are on the same plane it tries to
determine if one of the matrices is just a simple translation of the
other. In the process of this it also works out what the translation
would be. These values can be used to translate the clip rectangle
into the coordinate space of the rectangle to be logged. Then we can
do the clip directly in the rectangle's coordinate space.
When logging a quad we now only store the 2 vertices representing the
top left and bottom right of the quad. The color is only stored once
per entry. Once we come to upload the data we expand the 2 vertices
into four and copy the color to each vertex. We do this by mapping the
buffer and directly expanding into it. We have to copy the data before
we can render it anyway so it doesn't make much sense to expand the
vertices before uploading and this way should save some space in the
size of the journal. It also makes it slightly easier if we later want
to do pre-processing on the journal entries before uploading such as
doing software clipping.
The modelview matrix is now always copied to the journal entry whereas
before it would only be copied if we aren't doing software
transform. The journal entry struct always has the space for the
modelview matrix so hopefully it's only a small cost to copy the
matrix.
The transform for the four entries is now done using
cogl_matrix_transform_points which may be slightly faster than
transforming them each individually with a call to
cogl_matrix_transfom.
The features_cached member of CoglContext is intended to mark when
we've calculated the features so that we know if they are ready in
cogl_get_features. However we always intialize the features while
creating the context so features_cached will never be FALSE so it's
not useful. We also had the odd behaviour that the COGL_DEBUG feature
overrides were only applied in the first call to
cogl_get_features. However there are other functions that use the
feature flags such as cogl_features_available that don't use this
function so in some cases the feature flags will be interpreted before
the overrides are applied. This patch makes it always initialize the
features and apply the overrides immediately while creating the
context. This fixes a problem with COGL_DEBUG=disable-arbfp where the
first material flushed is done before any call to cogl_get_features so
it may still use ARBfp.
The GLSL pipeline backend can now generate code to represent the
pipeline state in a similar way to the ARBfp backend. Most of the code
for this is taken from the GLES 2 wrapper.
Only one of the material backends can be generating code at the same
time so it seems to make sense to share the same source buffer between
arbfp and glsl. The new name is fragment_source_buffer in case we
later want to create a new buffer for the vertex shader. That probably
couldn't share the same buffer because it will likely need to be
generated at the same time.
When COGL_ENABLE_EXPERIMENTAL_2_0_API is defined cogl.h will now include
cogl2-path.h which changes cogl_path_new() so it can directly return a
CoglPath pointer; it no longer exposes a prototype for
cogl_{get,set}_path and all the remaining cogl_path_ functions now take
an explicit path as their first argument.
The idea is that we want to encourage developers to retain path objects
for as long as possible so they can take advantage of us uploading the
path geometry to the GPU. Currently although it is possible to start a
new path and query the current path, it is not convenient.
The other thing is that we want to get Cogl to the point where nothing
depends on a global, current context variable. This will allow us to one
day define a sensible threading model if/when that is ever desired.
When using cogl_set_source_color4ub there is a notable difference
between colors that require blending and those that dont. When trying to
modify the color of pipeline referenced by the journal we don't force a
flush of the journal unless the color change will also change the
blending state. By using two separate pipeline objects for handing
opaque or transparent colors we can avoid ever flushing the journal when
repeatedly using cogl_set_source_color and jumping between opaque and
transparent colors.
Previously we tracked whether the clip stack needs flushing as part of
the CoglClipState which is part of the CoglFramebuffer state. This is
a bit odd because most of the clipping state (such as the clip planes
and the scissor) are part of the GL context's state rather than the
framebuffer. We were marking the clip state on the framebuffer dirty
every time we change the framebuffer anyway so it seems to make more
sense to have the dirtiness be part of the global context.
Instead of a just a single boolean to record whether the state needs
flushing, the CoglContext now holds a reference to the clip stack that
was flushed. That way we can flush arbitrary stack states and if it
happens to be the same as the state already flushed then Cogl will do
nothing. This will be useful if we log the clip stack in the journal
because then we will need to flush unrelated clip stack states for
each batch.
This applies an API naming change that's been deliberated over for a
while now which is to rename CoglMaterial to CoglPipeline.
For now the new pipeline API is marked as experimental and public
headers continue to talk about materials not pipelines. The CoglMaterial
API is now maintained in terms of the cogl_pipeline API internally.
Currently this API is targeting Cogl 2.0 so we will have time to
integrate it properly with other upcoming Cogl 2.0 work.
The basic reasons for the rename are:
- That the term "material" implies to many people that they are
constrained to fragment processing; perhaps as some kind of high-level
texture abstraction.
- In Clutter they get exposed by ClutterTexture actors which may be
re-inforcing this misconception.
- When comparing how other frameworks use the term material, a material
sometimes describes a multi-pass fragment processing technique which
isn't the case in Cogl.
- In code, "CoglPipeline" will hopefully be a much more self documenting
summary of what these objects represent; a full GPU pipeline
configuration including, for example, vertex processing, fragment
processing and blending.
- When considering the API documentation story, at some point we need a
document introducing developers to how the "GPU pipeline" works so it
should become intuitive that CoglPipeline maps back to that
description of the GPU pipeline.
- This is consistent in terminology and concept to OpenGL 4's new
pipeline object which is a container for program objects.
Note: The cogl-material.[ch] files have been renamed to
cogl-material-compat.[ch] because otherwise git doesn't seem to treat
the change as a moving the old cogl-material.c->cogl-pipeline.c and so
we loose all our git-blame history.
This updates the implementation of cogl_polygon so it sits on the new
CoglVertexArray and CoglVertexAttribute apis. This lets us minimize the
number of different drawing paths we have to maintain in Cogl.
Since the sliced texture support for cogl_polygon has been broken for a
long time now and no one has complained this patch also greatly
simplifies the code by not doing any special material validation so
cogl_polygon will be restricted in the same way as
cogl_draw_vertex_attributes. (i.e. sliced textures not supported).
Instead of using raw OpenGL in the journal we now use the vertex
attributes API instead. This is part of an ongoing effort to reduce the
number of drawing paths we maintain in Cogl.
The functionality of cogl_vertex_buffer_indices_get_for_quads is now
provided by cogl_get_rectangle_indices so this reworks the former to now
work in terms of the latter so we don't have duplicated logic.
CoglIndices define a range of indices inside a CoglIndexArray. I.e. a
CoglIndexArray is simply a buffer of N bytes and you can then
instantiate multiple CoglIndices collections that define a sub-region of
a CoglIndexArray by specifying a start offset and an index data type.
This allows _cogl_material_flush_gl_state to bail out faster if
repeatedly asked to flush the same material and we can see the material
hasn't changed.
Since we can rely on the material age incrementing when any material
property changes or any associated layer property changes then we can
track the age of the material after flushing so it can be compared with
the age of the material if it is subsequently re-flushed. If the age is
the same we only have to re-assert the texture object state.
Previously cogl_set_source_color and cogl_set_source_texture modified
a single global material. If an application then mixes using
cogl_set_source_color and texture then the material will constantly
need a new ARBfp program because the numbers of layers alternates
between 0 and 1. This patch just adds a second global material that is
only used for cogl_set_source_texture. I think it would still end up
flushing the journal if cogl_set_source_texture is used with multiple
different textures but at least it should avoid a recompile unless the
texture target also changes. It might be nice to somehow attach a
material to the CoglTexture for use with cogl_set_source_texture but
it would be difficult to implement this without creating a circular
reference.
This exposes the idea of a stack of source materials instead of just
having a single current material. This allows the writing of orthogonal
code that can change the current source material and restore it to its
previous state. It also allows the implementation of new composite
primitives that may want to validate the current source material and
possibly make override changes in a derived material.
*** WARNING: THIS COMMIT CHANGES THE BUILD ***
Do not recurse into the backend directories to build private, internal
libraries.
We only recurse from clutter/ into the cogl sub-directory; from there,
we don't recurse any further. All the backend-specific code in Cogl and
Clutter is compiled conditionally depending on the macros defined by the
configure script.
We still recurse from the top-level directory into doc, clutter and
tests, because gtk-doc and tests do not deal nicely with non-recursive
layouts.
This change makes Clutter compile slightly faster, and cleans up the
build system, especially when dealing with introspection data.
Ideally, we also want to make Cogl part of the top-level build, so that
we can finally drop the sed trick to change the shared library from the
GIR before compiling it.
Currently disabled:
‣ OSX backend
‣ Fruity backend
Currently enabled but untested:
‣ EGL backend
‣ Windows backend
