In _cogl_pipeline_needs_blending_enabled after first checking whether
the property most recently changed requires blending we would then
resort to checking all other properties too in case some other state
also requires blending. We now avoid checking all other properties in
the case that blending was previously disabled and checking the property
recently changed doesn't require blending.
Note: the plan is to improve this further by explicitly keeping track
of the properties that currently cause blending to be enabled so that we
never have to resort to checking all other properties we can constrain
the checks to those masked properties.
This moves _cogl_pipeline_get_parent and _cogl_pipeline_get_authority
into cogl-pipeline-private.h so they can be inlined since they have been
seen to get quite high in profiles. Given that they both contain such
small amounts of code the function call overhead is significant.
This adds a debug option called disable-software-clipping which causes
the journal to always log the clip stack state rather than trying to
manually clip rectangles.
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.
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 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.
This reverts commit 4cfe90bde2.
GLSL 1.00 on GLES doesn't support unsized arrays so the whole idea
can't work.
Conflicts:
clutter/cogl/cogl/cogl-pipeline-glsl.c
The check for whether we can reuse a program we've already generated
was only being done if the pipeline already had a
glsl_program_state. When there is no glsl_program_state it then looks
for the nearest ancestor it can share the program with. It then
wasn't checking whether that ancestor already had a GL program so it
would start generating the source again. It wouldn't however compile
that source again because _cogl_pipeline_backend_glsl_end does check
whether there is already a program. This patch moves the check until
after it has found the glsl_program_state, whether or not it was found
from an ancestor or as its own state.
Under GLES2 we were defining the cogl_tex_coord_in varying as an array
with a size determined by the number of texture coordinate arrays
enabled whenever the program is used. This meant that we may have to
regenerate the shader with a different size if the shader is used with
more texture coord arrays later. However in OpenGL the equivalent
builtin varying gl_TexCoord is simply defined as:
varying vec4 gl_TexCoord[]; /* <-- no size */
GLSL is documented that if you declare an array with no size then you
can only access it with a constant index and the size of the array
will be determined by the highest index used. If you want to access it
with a non-constant expression you need to redeclare the array
yourself with a size.
We can replicate the same behaviour in our Cogl shaders by instead
declaring the cogl_tex_coord_in with no size. That way we don't have
to pass around the number of tex coord attributes enabled when we
flush a material. It also means that CoglShader can go back to
directly uploading the source string to GL when cogl_shader_source is
called so that we don't have to keep a copy of it around.
If the user wants to access cogl_tex_coord_in with a non-constant
index then they can simply redeclare the array themself. Hopefully
developers will expect to have to do this if they are accustomed to
the gl_TexCoord array.
When compiling for GLES2, the codegen is affected by state other than
the layers. That means when we find an authority for the codegen state
we can't directly look at authority->n_layers to determine the number
of layers because it isn't necessarily the layer state authority. This
patch changes it to use cogl_pipeline_get_n_layers instead. Once we
have two authorities that differ in codegen state we then compare all
of the layers to decide if they would affect codegen. However it was
ignoring the fact that the authorities might also differ by the other
codegen state. This path also adds an extra check for whether
_cogl_pipeline_compare_differences contains any codegen bits other
than COGL_PIPELINE_STATE_LAYERS.
When determining if a layer would require a different shader to be
generated it needs to check a certain set of state changes and it
needs to check whether the texture target is different. However it was
checking whether texture texture was different only if the other state
was also different which doesn't make any sense. It also only checked
the texture difference if that was the only state change which meant
that effectively the code was impossible to reach. Now it does the
texture target check indepent of the other state changes.
The fixed pipeline backend wasn't correctly flushing the combine
constant because it was using the wrong flag to determine if the
combine constant has changed since the last flushed material.
When enabling a unit that was disabled from a previous flush pipeline
it was forgetting to rebind the right texture unit so it wouldn't
work. This was causing the redhand to disappear when using the fixed
function backend in test-cogl-multitexture if anything else is added
to the scene.
For shader generation backends we don't need to worry about changes to
the texture object and changing the user matrix. The missing user
matrix flag was causing test-cogl-multitexture to regenerate the
shader every frame.
Having ctx here produces a warning on GLES. However it's needed for Big
GL as we have at the top of the file:
#ifdef HAVE_COGL_GL
#define glClientActiveTexture ctx->drv.pf_glClientActiveTexture
#endif
This reverts commit 27a3a2056a.
In 6246c2bd6 I moved the code to add the boilerplate to a shader to a
separate function and also made it so that the common boilerplate is
added as a separate string to glShaderSource. However I didn't notice
that the #define for the vertex and fragment shaders already includes
the common part so it was being added twice. Mesa seems to accept this
but it was causing problems on the IMG driver because COGL_VERSION was
defined twice.
Before commit 49898d43 CoglPipeline would compare whether a pipeline
layer's texture is equal by fetching the underlying GL handle. I
changed that so that it would only compare the CoglHandles because
that commit removes the GL handle texture overrides and sliced
textures instead log the underlying primitive texture. However I
forgot that the primitives don't always use
_cogl_texture_foreach_sub_texture_in_region when the quad fits within
the single texture so it won't use a texture override. This meant that
atlas textures and sub textures get logged with the atlas handle so
the comparison still needs to be done using the GL handles. It might
be nice to add a CoglTexture virtual to get the underlying primitive
texture instead to avoid having the pipeline poke around with GL
handles.
If we have to make override changes to the user's source material to
handle cogl_polygon then we need to make sure we unref the override
material at the end.
Previously we used the layers->backend_priv[] members to determine when
to notify backends about layer changes, but it entirely up to the
backends if they want to associate private state with layers, even
though they may still be interested in layer change notifications (they
may associate layer related state with the owner pipeline).
We now make the observation that in
_cogl_pipeline_backend_layer_change_notify we should be able to assume
there can only be one backend currently associated with the layer
because we wouldn't allow changes to a layer with multiple dependants.
This means we can determine the backend to notify by looking at the
owner pipeline instead.
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.
Now that the GLSL backend can generate code it can effectively handle
any pipeline unless there is an ARBfp program. However with current
open source GL drivers the ARBfp compiler is more stable so it makes
sense to prefer ARBfp when possible. The GLSL backend is also lower
than the fixed function backend on the assumption that any driver that
supports GLSL will also support ARBfp so it's quicker to try the fixed
function backend next.
This adds COGL_DEBUG=disable-fixed to disable the fixed function
pipeline backend. This is needed to test the GLSL shader generation
because otherwise the fixed function backend would always override it.
We don't want to use gl_PointCoord to implement point sprites on big
GL because in that case we already use glTexEnv(GL_COORD_REPLACE) to
replace the texture coords with the point sprite coords. Although GL
also supports the gl_PointCoord variable, it requires GLSL 1.2 which
would mean we would have to declare the GLSL version and check for
it. We continue to use gl_PointCoord for GLES2 because it has no
glTexEnv function.
The GLES2 wrapper no longer needs to generate any fragment shader
state because the GLSL pipeline backend will always give the wrapper a
custom fragment shader. This simplifies a lot of the state comparison
done by the wrapper. The fog generation is also removed even though
it's actually part of the vertex shader because only the fixed
function pipeline backend actually calls the fog functions so it would
be disabled when using any of the other backends anyway. We can fix
this when the two shader backends also start generating vertex
shaders.
GLES2 has no glAlphaFunc function so we need to simulate the behaviour
in the fragment shader. The alpha test function is simulated with an
if-statement and a discard statement. The reference value is stored as
a uniform.
Previously the flag to mark the differences for the alpha test
function and reference value were conflated into one. However this is
awkward when generating shader code to simulate the alpha testing for
GLES 2 because in that case changing the function would need a
different program but changing the reference value just requires
updating a uniform. This patch makes the function and reference have
their own state flags.
The GLSL shader generation supports layer combine constants so there's
no need to disable it for GLES2. It looks like there was also code for
it in the GLES2 wrapper so I'm not sure why it was disabled in the
first place.
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.
_cogl_shader_compile_real had some code to create a set of strings to
combine the boilerplate code with a shader before calling
glShaderSource. This has now been moved to its own internal function
so that it could be used from the GLSL pipeline backend as well.
need_texture_combine_separate is moved to cogl-pipeline.c and renamed
to _cogl_pipeline_need_texture_combine_separate. The function is
needed by both the ARBfp and GLSL codegen backends so it makes sense to
share it.
The code for finding the arbfp authority for a pipeline should be the
same as finding the GLSL authority. So that the code can be shared the
function has been moved to cogl-pipeline.c and renamed to
_cogl_pipeline_find_codegen_authority.
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.
* cogl_texture_get_data() is converted to use
_cogl_texture_foreach_sub_texture_in_region() to iterate
through the underlying textures.
* When we need to read only a portion of the underlying
texture, we set up a FBO and use _cogl_read_pixels()
to read the portion we need. This is enormously more
efficient for reading a small portion of a large atlas
texture.
* The CoglAtlasTexture, CoglSubTexture, and CoglTexture2dSliced
implementation of get_texture() are removed.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2414
Previously in cogl_read_pixels we assume the format of the framebuffer
is always premultiplied because that is the most likely format with
the default Cogl blend mode. However when the framebuffer is bound to
a texture we should be able to make a better guess at the format
because we know the texture keeps track of the premult status. This
patch adds an internal format member to CoglFramebuffer. For onscreen
framebuffers we still assume it is RGBA_8888_PRE but for offscreen to
textures we copy the texture format. cogl_read_pixels uses this to
determine whether the data returned by glReadPixels will be
premultiplied.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2414
When converting the data in cogl_read_pixels it was using bmp_format
instead of the format passed in to the function. bmp_format is the
same as the passed in format except that it always has the premult bit
set. Therefore the conversion would not handle premultiply correctly.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2414
This is the same as _cogl_read_pixels except that it takes a rowstride
parameter for the destination buffer. Under OpenGL setting the
rowstride this will end up calling GL_ROW_LENGTH so that the buffer
region can be directly written to. Under GLES GL_ROW_LENGTH is not
supported so it will use an intermediate buffer as it does if the
format is not GL_RGBA.
cogl_read_pixels now just calls the full version of the function with
the rowstride set to width*bpp.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2414
This function is the same as cogl_offscreen_new_to_texture but it
takes a level parameter and a set of flags so that FBOs can be used to
render to higher mipmap levels and to disable the depth and stencil
buffers. cogl_offscreen_new_to_texture now just calls the new function
with the level set to zero. This function could be useful in a few
places in Cogl where we want to use FBOs as an implementation detail
such as when copying between textures.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2414
When uploading a 3D texture with an awkward rowstride, on GLES Cogl
will copy the images to an intermediate buffer to pass to GL. However
it was using the wrong height when copying the data so it would end up
overflowing the buffer and crashing.
Since we're using CoglPipelineWrapModeInternal in the internal API
anyway, and the compiler complains loudly when comparing two enumeration
types without casting, the PipelineLayer struct should store the
wrap modes using the internal enumeration.
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.
When logging quads in the journal it used to be possible to specify a
mask of fallback layers (layers where a default white texture should be
used in-place of the corresponding texture in the current source
pipeline). Since we now handle fallbacks for cogl_rectangle* primitives
when validating the pipeline up-front before logging in the journal we
no longer need the ability for the journal to apply fallbacks too.
This add two new function that allows us to transform or project an
array of points instead of only transforming one point at a time. Recent
benchmarking has shown cogl_matrix_transform_point to be a bottleneck
sometimes, so this should allow us to reduce the overhead when
transforming lots of vertices at the same time, and also reduce the cost
of 3 component, non-projective transforms.
For now they are marked as experimental (you have to define
COGL_ENABLE_EXPERIMENTAL_API) because there is some concern that it
introduces some inconsistent naming. cogl_matrix_transform_point would
have to be renamed cogl_matrix_project_point to be consistent, but that
would be an API break.
Switch _cogl_rectangles_with_multitexture_coords to using
_cogl_pipeline_foreach_layer to iterate the layers of a pipeline when
validating instead of iterating the pipelines internal list, which is
risky since any modifications to pipelines (even to an override pipeline
derived from the original), could potentially corrupt the list as it is
being iterated.
This removes the possibility to specify wrap mode overrides within a
CoglPipelineFlushOptions struct since the right way to handle these
overrides is by copying the user's material and making the changes to
that copy before flushing. All primitives code has already switched away
from using these wrap mode overrides so this patch just removes unused
code and types. It also remove the wrap_mode_overrides argument for
_cogl_journal_log_quad.
With the refactoring to centralize code into CoglBuffer,
_cogl_buffer_fini() was never actually implemented, so all GL
vertex and index buffer objects were leaked.
The duplicate call to glDeleteBuffers() in CoglPixelArray is
removed (it wasn't paying attention to whether the buffer had been
allocated as a PBO or not.)
http://bugzilla.clutter-project.org/show_bug.cgi?id=2423
This adds a COGL_DEBUG=wireframe option to visualize the underlying
geometry of the primitives being drawn via Cogl. This works for triangle
list, triangle fan, triangle strip and quad (internal only) primitives.
It also works for indexed vertex arrays.
In cogl_vertex_buffer_indices_get_for_quads() we sometimes have to
extend the length of an existing array, but when we came to unref the
previous array we didn't first check that it wasn't simply NULL.
This adds an optional data argument for cogl_vertex_array_new() since it
seems that mostly every case where we use this API we follow up with a
cogl_buffer_set_data() matching the size of the new array. This
simplifies all those cases and whenever we want to delay uploading of
data then NULL can simply be passed.
There's no longer any need to use the GL handle in the callback for
_cogl_texture_foreach_sub_texture_in_region because it can now work in
terms of primitive cogl textures so it has now been removed. This
would be helpful if we ever want to make the foreach function public
so that apps could implement their own primitives using sliced
textures.
Since d5634e37 the sliced texture backend now works in terms of
CoglTexture2Ds so there's no need to have special casing for
overriding the texture of a pipeline layer with a GL handle. Instead
we can just use cogl_pipeline_set_layer_texture with the
CoglHandle. The special _cogl_pipeline_set_layer_gl_texture_slice
function has now been removed and parts of the code for comparing
materials have been simplified.
The cogl_texture_foreach_sub_texture_in_region virtual for the sliced
texture backend was previously passing the CoglHandle of the sliced
texture to the callback. Since d5634e37 the slice texture backend now
works in terms of 2D textures so it's possible to pass the underlying
slice texture as a handle too. This makes all of the foreach callbacks
consistent in that they pass a CoglHandle of the primitive texture
type that matches the GL handle.
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.
For now this new define is simply an alias for
COGL_ENABLE_EXPERIMENTAL_API but the intention is that we will also use
it to start experimenting with changes that need to break the existing
Cogl API in incompatible ways.
We now prepend a set of defines to any given GLSL shader so that we can
define builtin uniforms/attributes within the "cogl" namespace that we
can use to provide compatibility across a range of the earlier versions
of GLSL.
This updates test-cogl-shader-glsl.c and test-shader.c so they no longer
needs to special case GLES vs GL when splicing together its shaders as
well as the blur, colorize and desaturate effects.
To get a feel for the new, portable uniform/attribute names here are the
defines for OpenGL vertex shaders:
#define cogl_position_in gl_Vertex
#define cogl_color_in gl_Color
#define cogl_tex_coord_in gl_MultiTexCoord0
#define cogl_tex_coord0_in gl_MultiTexCoord0
#define cogl_tex_coord1_in gl_MultiTexCoord1
#define cogl_tex_coord2_in gl_MultiTexCoord2
#define cogl_tex_coord3_in gl_MultiTexCoord3
#define cogl_tex_coord4_in gl_MultiTexCoord4
#define cogl_tex_coord5_in gl_MultiTexCoord5
#define cogl_tex_coord6_in gl_MultiTexCoord6
#define cogl_tex_coord7_in gl_MultiTexCoord7
#define cogl_normal_in gl_Normal
#define cogl_position_out gl_Position
#define cogl_point_size_out gl_PointSize
#define cogl_color_out gl_FrontColor
#define cogl_tex_coord_out gl_TexCoord
#define cogl_modelview_matrix gl_ModelViewMatrix
#define cogl_modelview_projection_matrix gl_ModelViewProjectionMatrix
#define cogl_projection_matrix gl_ProjectionMatrix
#define cogl_texture_matrix gl_TextureMatrix
And for fragment shaders we have:
#define cogl_color_in gl_Color
#define cogl_tex_coord_in gl_TexCoord
#define cogl_color_out gl_FragColor
#define cogl_depth_out gl_FragDepth
#define cogl_front_facing gl_FrontFacing
When converting the virtual coordinates of the underlying texture for
a slice to virtual coordinates for the whole texture it was using the
size and offset of the intersection as the size of the child
texture. This would be incorrect if the texture contains waste or the
texture coordinates are not the default. Instead the sliced foreach
function now passes the CoglSpan to the callback instead of the
intersection.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2398
Previously in the tests/tools directory we build a disable-npots
library which was used as an LD_PRELOAD to trick Cogl in to thinking
there is no NPOT texture extension. This is a little awkward to use so
it seems much simpler to just define a COGL_DEBUG option to disable
npot textures.
In some micro-benchmarks testing journal throughput the list
manipulation jumps pretty high in the profile. This replaces the GSList
usage with a GArray instead which is effectively a grow only allocation
that means we avoid ongoing allocations while manipulating the stack
mid-scene.
During _cogl_pipeline_needs_blending_enabled we were always checking the
current lighting properties (ambient,diffuse,specular,emission) which
had a notable impact during micro-benchmarks that exercise journal
throughput of simple colored rectangles. This #if 0's the offending code
considering that Cogl doesn't actually support lighting currently and
when it actually does then we will be able to optimize this by avoiding
the checks when lighting is disabled.
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.
This reworks _cogl_texture_quad_multiple_primitives so instead of using
the CoglPipelineWrapModeOverrides mechanism to force the clamp to edge
repeat mode we now derive an override pipeline using cogl_pipeline_copy
instead. This avoids a relatively large, unconditional, memset.
This avoids using the wrap mode overrides mechanism to implement
_cogl_multitexture_quad_single_primitive which requires memsetting a
fairly large array. This updates it to use cogl_pipeline_foreach_layer()
and we now derive an override_material to handle changes to the wrap
modes instead of using the CoglPipelineWrapModeOverrides.
Previously there was a check to avoid filling the path if there are
zero nodes. However the tesselator also won't generate any triangles
if there are less than 3 nodes so we might as well bail out in that
case too. If we don't emit any triangles then we would end up trying
to create an empty VBO. Although I don't think this should necessarily
be a problem, this seems to cause Mesa to segfault in version 7.8.1
when calling glBufferSubData (although not in
master). test-cogl-primitives tries to fill a path with only two
points so it's convenient to be able to avoid the crash in this case.
When adding a new entry to the journal a reference is now taken on the
current clip stack. Modifying the current clip state no longer causes
a journal flush. The journal flushing code now has an extra stage to
compare the clip state of each entry. The comparison can simply be
done by comparing the pointers. Although different clip states will
still end up with multiple draw calls this at leasts allows a scene
comprising of multiple different clips to be upload with one vbo. It
also lays the groundwork to do certain tricks when drawing clipped
rectangles such as modifying the geometry instead of setting a clip
state.
This adds a flag to avoid flushing the clip state when flushing the
framebuffer state. This will be used by the journal to manage its own
clip state flushing.
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.
CoglVertexAttribute has an internal draw function that is used by the
CoglJournal to avoid the call to cogl_journal_flush which would
otherwise end up recursively flushing the journal forever. The
enable_gl_state function called by this was previously also calling
_cogl_flush_framebuffer_state. However the journal code tries to
handle this function specially by calling it with a flag to disable
flushing the modelview matrix. This is useful because the journal
handles flushing the modelview itself. Without this patch the journal
state ends up getting flushed twice. This isn't a particularly big
problem currently because the matrix stack has caching to recognise
when it would push the same state twice and bails out. However if we
later want to use the framebuffer flush flags to override a particular
state of the framebuffer (such as the clip state) then we need to make
sure the flush isn't called twice.
Unless the CoglBuffer is being used for texture data then it's
relatively unlikely that the data will contain an array of bytes. For
example if it's used as a vertex array then it's more likely to be
floats or some vertex struct. In that case it's much more convenient
if set_data and map use void* pointers so that we can avoid a cast.
The convenience constructors for the builtin vertex structs were
creating the primitive and then immediately destroying it and
returning the pointer. I think the intention was to unref the
attributes instead. This adds an internal wrapper around the
new_with_attributes_array constructor which unrefs the attributes
instead of the primitive. The convenience constructors now use that.
The GLES2 wrapper was referring to COGL_MATERIAL_PROGRAM_TYPE_GLSL but
this has since been renamed to COGL_PIPELINE_PROGRAM_TYPE_GLSL so the
GLES2 backend wouldn't compile.
The gles2 wrapper functions don't understand about the CoglBuffer API so
they don't support attributes stored in a CoglVertexArray. Instead of
teaching the backend about buffers we are going to wait until we have
overhauled the GLES 2 backend. We are currently making progress
consolidating the GLES 2 backend with a new GLSL backend for
CoglMaterial. This will hugely simplify the GLES 2 support and share
code with the OpenGL backend. In the end it's hoped that this problem
will simply go away so it doesn't make much sense to solve it with the
current design.
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.
Instead of using the CoglHandle type for material variables this updates
the pango code to use CoglMaterial * instead. CoglHandle is the old
typename which is being phased out of the API.
The pango-display-list code was calling cogl_set_source in numerous
places and it didn't appear to be saving the users source to restore
later. This could result in the user inadvertantly drawing a primitive
with one of these internally managed materials instead of one that they
chose. To rectify this the code now uses cogl_{push,pop}_source to save
and restore the users source.
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).
