On GLES2 there's no builtin mechanism to replace texture coordinates
with point sprite coordinates so calling glEnable(GL_POINT_SPRITE)
isn't valid. Instead the point sprite coords are implemented by using
a special builtin varying variable in GLSL.
There are several places where we need to compare the texture state of a
pipeline and sometimes we need to take into consideration if the
underlying texture has changed but other times we may only care to know
if the texture target has changed.
For example the fragends typically generate programs that they want to
share with all pipelines with equivalent fragment processing state, and
in this case when comparing pipelines we only care about the texture
targets since changes to the underlying texture won't affect the
programs generated.
Prior to this we had tried to handle this by passing around some special
flags to various functions that evaluate pipeline state to say when we
do/don't care about the texture data, but this wasn't working in all
cases and was more awkward to manage than the new approach.
Now we simply have two state bits:
COGL_PIPELINE_LAYER_STATE_TEXTURE_TARGET and
COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA and CoglPipelineLayer has an
additional target member. Since all the appropriate code takes masks of
these state bits to determine what to evaluate we don't need any extra
magic flags.
When notifying that a pipeline property is going to change, then at
times a pipeline will take over being the authority of the corresponding
state group. Some state groups can contain multiple properties and so to
maintain the integrity of all of the properties we have to initialize
all the property values in the new authority. For state groups with only
one property we don't have to initialize anything during the
pre_change_notify() because we can assume the value will be initialized
as part of the change being notified.
This patch optimizes how we handle this initialization of state groups
in a couple of ways; firstly we no longer do anything to initialize
state-groups with only one property, secondly we no longer use
_cogl_pipeline_copy_differences - (we have a new
_cogl_pipeline_init_multi_property_sparse_state() func) so we can avoid
lots calls to handle_automatic_blend_enable() which is sometimes seen
high in sysprof profiles.
Atlasing needs to be disabled for the hand texture so that it can work
out the step value needed to fetch a neighbouring pixel in the blur
shader. If the texture ends up in the atlas then the test can't know
the actual size of the texture so it looks wrong.
Previously atlasing would be disabled if the GL driver does not
support reading back texture data. This meant that atlasing would not
happen on GLES. However we also require that the driver support FBOs
and the texture data is only read back as a fallback if the FBO
fails. Therefore the atlas should be ok on GLES 2 which has FBO
support in core.
We try and bail out of flushing pipeline state asap if we can see the
pipeline has already been flushed and hasn't changed but we weren't
checking to see if the skip_gl_color flag is the same as when it was
last flush too and so we'd sometimes bail out without updating the
glColor correctly.
When an item is added to the journal the current pipeline immediately
gets the legacy state applied to it and the modified pipeline is
logged instead of the original. However the actual drawing from the
journal is done using the vertex attribute API which was also applying
the legacy state. This meant that the legacy state used would be a
combination of the state set when the journal entry was added as well
as the state set when the journal is flushed. To fix this there is now
an extra CoglDrawFlag to avoid applying the legacy state when setting
up the GL state for the vertex attributes. The journal uses this flag
when flushing.
clutter_shader_finalize() was calling clutter_shader_release() which in
turn notifies "compiled". GObject was complaining that we were trying to
_ref() an object that was in _finalize().
#0 g_log (log_domain=0x3e15c4 "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL,
format=0x76c938 "%s: assertion `%s' failed") at gmessages.h:97
#1 0x0070777d in g_return_if_fail_warning (
log_domain=0x3e15c4 "GLib-GObject",
pretty_function=0x3e37a4 "g_object_ref",
expression=0x3e2a00 "object->ref_count > 0") at gmessages.c:586
#2 0x003b862b in g_object_ref (_object=0x8567af0) at gobject.c:2615
#3 0x003bd238 in g_object_notify_by_pspec (object=0x8567af0, pspec=0x87ea2f0)
at gobject.c:1075
#4 0x00b6500b in clutter_shader_release (shader=0x8567af0)
at ./clutter-shader.c:612
#5 0x00b659b9 in clutter_shader_finalize (object=0x8567af0)
at ./clutter-shader.c:107
Then, let's split release in two, with an _internal() version that does
not notify "compiled" and use it from dispose (as the object is still
usable after a call to release_internal().
http://bugzilla.clutter-project.org/show_bug.cgi?id=2512
The vertex attribute API assumes that if there is a color array
enabled then we can't determine if the colors are opaque so we have to
enable blending. The journal always uses a color array to avoid
switching color state between rectangles. Since the journal switched
to using vertex attributes this means we effectively always enable
blending from the journal. To fix this there is now a new flag for
_cogl_draw_vertex_attributes to specify that the color array is known
to only contain opaque colors which causes the draw function not to
copy the pipeline. If the pipeline has blending disabled then the
journal passes this flag.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2481
There is an internal version of cogl_draw_vertex_attributes_array
which previously just bypassed the framebuffer flushing, journal
flushing and pipeline validation so that it could be used to draw the
journal. This patch generalises the function so that it takes a set of
flags to specify which parts to flush. The public version of the
function now just calls the internal version with the flags set to
0. The '_real' version of the function has now been merged into the
internal version of the function because it was only called in one
place. This simplifies the code somewhat. The common code which
flushed the various state has been moved to a separate function. The
indexed versions of the functions have had a similar treatment.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2481
Cogl no longer has any code that assumes the buffer in a CoglBitmap is
allocated to the full size of height*rowstride. We should comment that
this is the case so that we remember to keep it that way. This is
important for cogl_texture_new_from_data because the application may
have created the data from a sub-region of a larger image and in that
case it's not safe to read the full rowstride of the last row when the
sub region contains the last row of the larger image.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2491
When uploading data for GLES we need to deal with cases where the
rowstride is too large to be described only by GL_UNPACK_ALIGNMENT
because there is no GL_UNPACK_ROW_LENGTH. Previously for the
sub-region uploading code it would always copy the bitmap and for the
code to upload the whole image it would copy the bitmap unless the
rowstride == bpp*width. Neither paths took into account that we don't
need to copy if the rowstride is just an alignment of bpp*width. This
moves the bitmap copying code to a separate function that is used by
both upload methods. It only copies the bitmap if the rowstride is not
just an alignment of bpp*width.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2491
The ffs function is defined in C99 so if we want to use it in Cogl we
need to provide a fallback for MSVC. This adds a configure check for
the function and then a fallback using a while loop if it is not
available.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2491
If we have to copy the bitmap to do the premultiplication then we were
previously using the rowstride of the source image as the rowstride
for the new image. This is wasteful if the source image is a subregion
of a larger image which would make it use a large rowstride. If we
have to copy the data anyway we might as well compact it to the
smallest rowstride. This also prevents the copy from reading past the
end of the last row of pixels.
An internal function called _cogl_bitmap_copy has been added to do the
copy. It creates a new bitmap with the smallest possible rowstride
rounded up the nearest multiple of 4 bytes. There may be other places
in Cogl that are currently assuming we can read height*rowstride of
the source buffer so they may want to take advantage of this function
too.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2491
The builtin vertex attribute for the normals was incorrectly checked
for as 'cogl_normal' however it is defined as cogl_normal_in in the
shader boilerplate and for the name generated by CoglVertexBuffer.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2499
Implement the ClutterStageWindow::set_accept_focus() virtual function in
the win32 backend.
If accept_focus is set to be TRUE then we call SetforegroundWindow()
after calling ShowWindow(). This is similar to what GDK does when
dealing with the same situation.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2500
Allow the developer to set whether the Stage should receive key focus
when mapped. The implementation is fully backend-dependent. The default
value is TRUE because that's what we've been expecting so far.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2500
If an actor is (unfortunately) queuing a relayout in relayout, you would
end up with (ClutterActor*)stage->needs_allocation set to TRUE and
stage->relayout_pending set to TRUE. But if then in the same cycle, an
actor calls clutter_actor_get_allocation_box, that will trigger another
(recursive) _clutter_stage_maybe_relayout, which will wrongly reset the
relayout pending to FALSE, while not actually performing a new relayout
because of the re-entrancy protection.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2503
Keeping the Cogl 2.0 API reference in the build is getting far more
troublesome than it's worth.
It's breaking distcheck far too often, and it makes it impossible to
rebuild the build environment from tarballs - which is something that
some distributions (namely: the Debian-based ones, but not limited to
them) do in order to change build scripts using their own rules.
