Since we've had several developers from admirable projects say they
would like to use Cogl but would really prefer not to pull in
gobject,gmodule and glib as extra dependencies we are investigating if
we can get to the point where glib is only an optional dependency.
Actually we feel like we only make minimal use of glib anyway, so it may
well be quite straightforward to achieve this.
This adds a --disable-glib configure option that can be used to disable
features that depend on glib.
Actually --disable-glib doesn't strictly disable glib at this point
because it's more helpful if cogl continues to build as we make
incremental progress towards this.
The first use of glib that this patch tackles is the use of
g_return_val_if_fail and g_return_if_fail which have been replaced with
equivalent _COGL_RETURN_VAL_IF_FAIL and _COGL_RETURN_IF_FAIL macros.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Cogl doesn't currently expose public api for clip planes so it
doesn't make much sense to have this feature as part of the public api.
We can't break the api by removing the enum but at least we no longer
ever set the feature flag.
We now have a replacement private feature flag
COGL_PRIVATE_FEATURE_FOUR_CLIP_PLANES which cogl now checks for
internally.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This adds a new experimental function, cogl_clip_push_primitive, that
allows you to push a CoglPrimitive onto the clip stack. The primitive
should describe a flat 2D shape and the geometry shouldn't include any
self intersections. When pushing a primitive you also need to tell
Cogl what the bounding box of that shape is (in shape local coordinates)
so that Cogl is able to efficiently update the required region of the
stencil buffer.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The code that adds the silhouette of a path to the stencil buffer was
living in cogl2-path.c which seemed out of place when the bulk of the
work really related more to how the stencil buffer is managed and
basically only one line (a call to _cogl_path_fill_nodes) really related
to the path code directly.
This moves the code into cogl-clip-stack.c alone with similar code
that can add rectangle masks to the stencil buffer.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Some code in Cogl such as when flushing a stencil clip assumes that it
can push a temporary simple pipeline to reset to a known state for
internal drawing operations. However this breaks down if the
application has set any legacy state because that is set globally so
it will also get applied to the internal pipeline.
_cogl_draw_attributes already had an internal flag to disable applying
the legacy state but I think this is quite awkward to use because not
all places that push a pipeline draw the attribute buffers directly so
it is difficult to pass the flag down through the layers.
Conceptually the legacy state is meant to be like a layer on top of
the purely pipeline-based state API so I think ideally we should have
an internal function to push the source without the applying the
legacy state. The legacy state can't be applied as the pipeline is
pushed because the global state can be modified even after it is
pushed. This patch adds a _cogl_push_source() function which takes an
extra boolean flag to mark whether to enable the legacy state. The
value of this flag is stored alongside the pipeline in the pipeline
stack. Another new internal function called
_cogl_get_enable_legacy_state queries whether the top entry in the
pipeline stack has legacy state enabled. cogl-primitives and the
vertex array drawing code now use this to determine whether to apply
the legacy state when drawing. The COGL_DRAW_SKIP_LEGACY_STATE flag is
now removed.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Some of the functions we were calling in cogl_framebuffer_clear[4f] were
referring to the current framebuffer, which would result in a crash
if nothing had been pushed before trying to explicitly clear a given
framebuffer.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The GL or GLES library is now dynamically loaded by the CoglRenderer
so that it can choose between GL, GLES1 and GLES2 at runtime. The
library is loaded by the renderer because it needs to be done before
calling eglInitialize. There is a new environment variable called
COGL_DRIVER to choose between gl, gles1 or gles2.
The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have
been changed so that they don't assume the ifdefs are mutually
exclusive. They haven't been removed entirely so that it's possible to
compile the GLES backends without the the enums from the GL headers.
When using GLX the winsys additionally dynamically loads libGL because
that also contains the GLX API. It can't be linked in directly because
that would probably conflict with the GLES API if the EGL is
selected. When compiling with EGL support the library links directly
to libEGL because it doesn't contain any GL API so it shouldn't have
any conflicts.
When building for WGL or OSX Cogl still directly links against the GL
API so there is a #define in config.h so that Cogl won't try to dlopen
the library.
Cogl-pango previously had a #ifdef to detect when the GL backend is
used so that it can sneakily pass GL_QUADS to
cogl_vertex_buffer_draw. This is now changed so that it queries the
CoglContext for the backend. However to get this to work Cogl now
needs to export the _cogl_context_get_default symbol and cogl-pango
needs some extra -I flags to so that it can include
cogl-context-private.h
cogl-ext-functions.h now contains definitions for all of the core GL
and GLES functions that we would normally link to directly. All of the
code has changed to access them through the cogl context pointer. The
GE macro now takes an extra parameter to specify the context because
the macro itself needs to make GL calls but various points in the Cogl
source use different names for the context variable.
It's generally useful to be able to query the width and height of a
framebuffer and we expect to need this in Clutter when we move the
eglnative backend code into Cogl since Clutter will need to read back
the fixed size of the framebuffer when realizing the stage.
This renames the two internal functions _cogl_get_draw/read_buffer
as cogl_get_draw_framebuffer and _cogl_get_read_framebuffer. The
former is now also exposed as experimental API.
Drawing and clipping to paths is generally quite expensive because the
geometry has to be tessellated into triangles in a single VBO which
breaks up the journal batching. If we can detect when the path
contains just a single rectangle then we can instead divert to calling
cogl_rectangle which will take advantage of the journal, or by pushing
a rectangle clip which usually ends up just using the scissor.
This patch adds a boolean to each path to mark when it is a
rectangle. It gets cleared whenever a node is added or gets set to
TRUE whenever cogl2_path_rectangle is called. This doesn't try to
catch cases where a rectangle is composed by cogl_path_line_to and
cogl_path_move_to commands.
The current framebuffer is now internally separated so that there can
be a different draw and read buffer. This is required to use the
GL_EXT_framebuffer_blit extension. The current draw and read buffers
are stored as a pair in a single stack so that pushing the draw and
read buffer is done simultaneously with the new
_cogl_push_framebuffers internal function. Calling
cogl_pop_framebuffer will restore both the draw and read buffer to the
previous state. The public cogl_push_framebuffer function is layered
on top of the new function so that it just pushes the same buffer for
both drawing and reading.
When flushing the framebuffer state, the cogl_framebuffer_flush_state
function now tackes a pointer to both the draw and the read
buffer. Anywhere that was just flushing the state for the current
framebuffer with _cogl_get_framebuffer now needs to call both
_cogl_get_draw_buffer and _cogl_get_read_buffer.
When flushing a clip stack that contains more than one rectangle which
needs to use the stencil buffer the code takes a different path so
that it can combine the new rectangle with the existing contents of
the stencil buffer. However it was not correctly flushing the
modelview and projection matrices so that rectangle would be in the
wrong place.
This adds a COGL_DEBUG=clipping option that reports how the clip is
being flushed. This is needed to determine whether the scissor,
stencil clip planes or software clipping is being used.
This adds an internal function to be able to query the screen space
bounding box of the current clip entries contained in a given
CoglClipStack.
This bounding box which is cheap to determine can be useful to know the
largest extents that might be updated while drawing with this clip
stack.
For example the plan is to use this as part of an optimized read-pixel
path handled on the CPU which will need to track the currently valid
extents of the last call to cogl_clear()
The GLES2 wrapper is no longer needed because the shader generation is
done within the GLSL fragend and vertend and any functions that are
different for GLES2 are now guarded by #ifdefs.
Previously in cogl-clip-state.c when it detected that the current
modelview matrix is screen-aligned it would convert the clip entry to
a window clip. Instead of doing this cogl-clip-stack.c now contains
the detection and keeps the entry as a rectangle clip but marks that
it is entirely described by its scissor rect. When flusing the clip
stack it doesn't do anything extra for entries that have this mark
(because the clip will already been setup by the scissor). This is
needed so that we can still track the original rectangle coordinates
and modelview matrix to help detect when it would be faster to modify
the rectangle when adding it to the journal rather than having to
break up the batch to set the clip state.
When using clip planes and we we have to project some vertices into
screen coordinates we used to transform those by the modelview and then
the projection matrix separately. Now we combine the modelview and
projection matrix and then use that to transform the vertices in one
step instead.
Flushing the clip state no longer does anything that would cause the
journal to flush. The clip state is only flushed when flushing the
framebuffer state and in all cases this ends up flushing the journal
in one way or another anyway. Avoiding flushing the journal will make
it easier to log the clip state in the journal.
Previously when trying to set up a rectangle clip that can't be
scissored or when using a path clip the code would use cogl_rectangle
as part of the process to fill the stencil buffer. This is now changed
to use a new internal _cogl_rectangle_immediate function which
directly uses the vertex array API to draw a triangle strip without
affecting the journal. This should be just as efficient as the
previous journalled code because these places would end up flushing
the journal immediately before and after submitting the single
rectangle anyway and flushing the journal always creates a new vbo so
it would effectively do the same thing.
Similarly there is also a new internal _cogl_clear function that does
not flush the journal.
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.
Instead of having a separate CoglHandle for CoglClipStack the code is
now expected to directly hold a pointer to the top entry on the
stack. The empty stack is then the NULL pointer. This saves an
allocation when we want to copy the stack because we can just take a
reference on a stack entry. The idea is that this will make it
possible to store the clip stack in the journal without any extra
allocations.
The _cogl_get_clip_stack and set functions now take a CoglClipStack
pointer instead of a handle so it would no longer make sense to make
them public. However I think the only reason we would have wanted that
in the first place would be to save the clip state between switching
FBOs and that is no longer necessary.
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 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.
This adds a COGL_OBJECT_INTERNAL_DEFINE macro and friends that are the
same as COGL_OBJECT_DEFINE except that they prefix the cogl_is_*
function with an underscore so that it doesn't get exported in the
shared library.
GLES2 doesn't provide user clip planes (you would have to use a vertex +
fragment shader to achieve the same kind of result) so we make sure not
to call glEnable/Disable with any of the GL_CLIP_PLANE0..3 defines.
http://bugzilla.o-hand.com/show_bug.cgi?id=2177
Whenever a path or a rectangle is added to the clip stack it now also
stores a screen space bounding box in the entry. Then when the clip
stack is flushed the bounding box is first used to set up the
scissor. That way when we eventually come to use the stencil buffer
the clear will be affected by the scissor so we don't have to clear
the entire buffer.
This replaces the use of CoglHandle with strongly type CoglClipStack *
pointers instead. The only function not converted for now is
cogl_is_clip_stack which will be done in a later commit.
If the clip stack is empty then _cogl_clip_stack_flush exits
immediately. This was missing out the assignment of *stencil_used_p at
the bottom of the function. If a path is then used after the clip is
cleared then it would think it needs to merge with the clip so the
stencil would not be cleared correctly.
Previously the clip stack code was trying to detect when the
orientation of the on-screen rectangle had changed by checking if the
order of the y-coordinates on the left edge was different from the
order the x-coordinates on the top edge. This doesn't work for some
rotations which was causing the clip planes to clip the wrong side of
the line. This patch makes it detect the orientation by calculating
the signed area which is a standard computer graphics algorithm.
http://bugzilla.openedhand.com/show_bug.cgi?id=2079
This adds three new internal API functions which can be used to retain
the clip stack state and restore it later:
_cogl_get_clip_stack
_cogl_set_clip_stack
_cogl_clip_stack_copy
The functions are currently internal and not yet used but we may want
to make them public in future to replace the cogl_clip_stack_save()
and cogl_clip_stack_restore() APIs.
The get function just returns the handle to the clip stack at the top
of the stack of stacks and the set function just replaces it.
The copy function makes a cheap copy of an existing stack by taking a
reference to the top stack entry. This ends up working like a deep
copy because there is no way to modify entries of a stack but it
doesn't actually copy the data.
CoglClipStackState has now been renamed to CoglClipState and is moved
to a separate file. CoglClipStack now just maintains a stack and
doesn't worry about the rest of the state. CoglClipStack sill contains
the code to flush the stack to GL.
When glScissor is called it needs to pass coordinates in GL's
coordinate space where the origin is the bottom left. Previously this
conversion was done before storing the window rect in the clip
stack. However this might make it more difficult if we want to be able
to grab a handle to a clip stack and use it in different circumstances
later. This patch moves the coordinate conversion to inside the clip
state flushing code.
The stack is now stored as a list of reference counted entries.
Instead of using a GList, each entry now contains a link with a
reference to its parent. The idea is that this would allow copying
stacks with a shared ancestry.
Previously the code flushed the state by finding the bottom of the
stack and then applying each entry by walking back up to the top. This
is slightly harder to do now because the list is no longer
doubly-linked. However I don't think it matters which order the
entries are applied so I've just changed it to apply them in reverse
order.
There was also a restriction that if ever the stencil buffer is used
then we could no longer use clip planes for any subsequent entries. I
don't think this makes sense because it should always work as long as
it doesn't attempt to use the clip planes more than once. I've
therefore removed the restriction.
This adds three new API calls:
CoglHandle cogl_path_get()
void cogl_path_set(CoglHandle path)
CoglHandle cogl_path_copy(CoglHandle path)
All of the fields relating to the path have been moved from the Cogl
context to a new CoglPath handle type. The cogl context now just
contains a CoglPath handle. All of the existing path commands
manipulate the data in the current path handle. cogl_path_new now just
creates a new path handle and unrefs the old one.
The path handle can be stored for later with cogl_path_get. The path
can then be copied with cogl_path_copy. Internally it implements
copy-on-write semantics with an extra optimisation that it will only
copy the data if the new path is modified, but not if the original
path is modified. It can do this because the only way to modify a path
is by appending to it so the copied path is able to store its own path
length and only render the nodes up to that length. For this to work
the copied path also needs to keep its own copies of the path extents
because the parent path may change these by adding nodes.
The clip stack now uses the cogl_path_copy mechanism to store paths in
the stack instead of directly copying the data. This should save some
memory and processing time.
Since using addresses that might change is something that finally
the FSF acknowledge as a plausible scenario (after changing address
twice), the license blurb in the source files should use the URI
for getting the license in case the library did not come with it.
Not that URIs cannot possibly change, but at least it's easier to
set up a redirection at the same place.
As a side note: this commit closes the oldes bug in Clutter's bug
report tool.
http://bugzilla.openedhand.com/show_bug.cgi?id=521
The size and position of the window rectangle for clipping in
try_pushing_rect_as_window_rect is calculated by projecting the
rectangle coordinates. Due to rounding errors, this can end up with
slightly off numbers like 34.999999. These were then being cast
directly to an integer so it could end up off by one.
This uses a new macro called COGL_UTIL_NEARBYINT which is a
replacement for the C99 nearbyint function.
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
cogl_push_draw_buffer, cogl_set_draw_buffer and cogl_pop_draw_buffer are now
deprecated and new code should use the new cogl_framebuffer_* API instead.
Code that previously did:
cogl_push_draw_buffer ();
cogl_set_draw_buffer (COGL_OFFSCREEN_BUFFER, buffer);
/* draw */
cogl_pop_draw_buffer ();
should now be re-written as:
cogl_push_framebuffer (buffer);
/* draw */
cogl_pop_framebuffer ();
As can be seen from the example above the rename has been used as an
opportunity to remove the redundant target argument from
cogl_set_draw_buffer; it now only takes one call to redirect to an offscreen
buffer, and finally the term framebuffer may be a bit more familiar to
anyone coming from an OpenGL background.
When _cogl_add_path_to_stencil_buffer is used to draw a path we don't
need to clear the entire stencil buffer. Instead it can clear just the
bounding box of the path. This adds an extra parameter called
'need_clear' which is only set if the stencil buffer is being used for
clipping.
http://bugzilla.openedhand.com/show_bug.cgi?id=1829
cogl_clip_push() which accepts a rectangle in model space shouldn't have
been defined to take x,y,width,height arguments because this isn't consistant
with other Cogl API dealing with model space rectangles. If you are using a
coordinate system with the origin at the center and the y+ extending up,
then x,y,width,height isn't as natural as (x0,y0)(x1,y1). This API has
now been replace with cogl_clip_push_rectangle()
(As a general note: the Cogl API should only use the x,y,width,height style
when the appropriate coordinate space is defined by Cogl to have a top left
origin. E.g. window coordinates, or potentially texture coordinates)
cogl_clip_push_window_rect() shouldn't have been defined to take float
arguments since we only clip with integral pixel precision. We also
shouldn't have abbreviated "rectangle". This API has been replaced with
cogl_clip_push_window_rectangle()
cogl_clip_ensure() wasn't documented at all in Clutter 1.0 and probably
no one even knew it existed. This API isn't useful, and so it's now
deprecated. If no one complains we may remove the API altogether for
Clutter 1.2.
cogl_clip_stack_save() and cogl_clip_stack_restore() were originally added
to allow us to save/restore the clip when switching to/from offscreen
rendering. Now that offscreen draw buffers are defined to own their clip
state and the state will be automatically saved and restored this API is now
redundant and so deprecated.
Firstly this now uses the draw buffer height not the viewport height
when we need to perform a y = height - y conversion, since (as the
name suggests) we are dealing with window coordinates not viewport
coordinates.
Secondly this skips any conversion when the current draw buffer is an
offscreen draw buffer since offscreen rendering is always forced to be
upside down and in this case Cogl window coordinates == GL window
coordinates.
