The pipeline function _cogl_pipeline_find_codegen_authority has been
renamed to _cogl_pipeline_find_equivalent_parent and it now takes a
set of flags for the pipeline and layer state that affects the
authority. This is needed so that we can reuse the same code in the
vertend and progends.
Previously enabling and disabling textures was done whatever the
backend in cogl-pipeline-opengl. However enabling and disabling
texture targets only has any meaning if no fragment shaders are being
used so this patch moves the code to cogl-pipeline-fragend-fixed.
The GLES2 wrapper has also been changed to ignore enabledness when
deciding whether to update texture coordinate attribute pointers.
Previously enabling and disabling textures was done whatever the
backend in cogl-pipeline-opengl. However enabling and disabling
texture targets only has any meaning if no fragment shaders are being
used so this patch moves the code to cogl-pipeline-fragend-fixed.
The GLES2 wrapper has also been changed to ignore enabledness when
deciding whether to update texture coordinate attribute pointers.
The current Cogl pipeline backends are entirely concerned with the
fragment processing state. We also want to eventually have separate
backends to generate shaders for the vertex processing state so we
need to rename the fragment backends. 'Fragend' is a somewhat weird
name but we wanted to avoid ending up with illegible symbols like
CoglPipelineFragmentBackendGlslPrivate.
The current Cogl pipeline backends are entirely concerned with the
fragment processing state. We also want to eventually have separate
backends to generate shaders for the vertex processing state so we
need to rename the fragment backends. 'Fragend' is a somewhat weird
name but we wanted to avoid ending up with illegible symbols like
CoglPipelineFragmentBackendGlslPrivate.
While we do check for compatibility and transformability of a GValue
with the GParamSpec value type, we are actually failing really badly
at it.
First of all, we bail out on the wrong conditions.
Then we use the type of the value passed instead of using the type
of the property itself.
This makes it impossible to actually use transformation functions for
GValue types - even those that have been registered by GLib itself -
when using the Animation API directly, instead of going through the
clutter_actor_animate() wrappers.
The ParamSpec sub-classes we define are meant to be used only from the C
API, as high-level languages completely ignore them.
The ClutterStageWindow interface is an internal type that escaped into
the public headers; all its methods are private, but we cannot remove
the type until we break for 2.0.
Maximized tiled windows end up with an inconsistent tile mode when
unmaximized by other means than dragging the window free (e.g.
using the unmaximize button or double clicking the title bar), so
reset the tile mode when unmaximizing.
This is not a problem for side-by-side tiling, as there are no
alternatives to dragging the window free.
The check-news option in configure.ac conflicts with the idea of using a
buildbot to do a distcheck.
Since we're doing some validation on the state of the build during the
release-check phase we should add the NEWS file check there.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2468
If an <emphasis> element is placed inside a <programlisting> in a cookbook
recipe, the result is bold italic text in the HTML output. This isn't
particularly readable.
Fix is to style emphasis elements inside programlistings
so the font weight is not bold but is still italicised.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2475
Currently clutter_list_model_get_iter_at_row() always returns an
iterator to the last non-filtered row when asking for row [1-N].
Patch makes the function return an iterator to the Nth non-filtered
row or NULL.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2460
Adapt to changes from these wayland commits:
35fd2a8cc68c42d90756330535de04cbbb4d2613
2bb3ebe1e437acf836449f0a63f3264ad29566f2
f8fc08f77187f6a5723281dab66841e5f3c24320
http://bugzilla.clutter-project.org/show_bug.cgi?id=2474
We are currently using a pipeline as a key into our arbfp program cache
but because we weren't making a copy of the pipelines used as keys there
were times when doing a lookup in the cache would end up trying to
compare a lookup key with an entry key that would point to invalid
memory.
Note: the current approach isn't ideal from the pov that that key
pipeline may reference some arbitrarily large user textures will now be
kept alive indefinitely. The plan to improve on this is that we will
have a mechanism to create a special "key pipeline" which will derive
from the default Cogl pipeline (to avoid affecting the lifetime of
other pipelines) and only copy state from the original pipeline that
affects the arbfp program and will reference small dummy textures
instead of potentially large user textures.
We are currently using a pipeline as a key into our arbfp program cache
but because we weren't making a copy of the pipelines used as keys there
were times when doing a lookup in the cache would end up trying to
compare a lookup key with an entry key that would point to invalid
memory.
Note: the current approach isn't ideal from the pov that that key
pipeline may reference some arbitrarily large user textures will now be
kept alive indefinitely. The plan to improve on this is that we will
have a mechanism to create a special "key pipeline" which will derive
from the default Cogl pipeline (to avoid affecting the lifetime of
other pipelines) and only copy state from the original pipeline that
affects the arbfp program and will reference small dummy textures
instead of potentially large user textures.
In the arbfp backend there is a seqential approach to finding a suitable
arbfp program to use for a given pipeline; first we see if there's
already a program associated with the pipeline, 2nd we try and find a
program associated with the "arbfp-authority" 3rd we try and lookup a
program in a cache and finally we resort to starting code-generation for
a new program. This patch slightly reworks the code of these steps to
hopefully make them a bit clearer.
In the arbfp backend there is a seqential approach to finding a suitable
arbfp program to use for a given pipeline; first we see if there's
already a program associated with the pipeline, 2nd we try and find a
program associated with the "arbfp-authority" 3rd we try and lookup a
program in a cache and finally we resort to starting code-generation for
a new program. This patch slightly reworks the code of these steps to
hopefully make them a bit clearer.
_cogl_pipeline_needs_blending_enabled tries to determine whether each
layer is using the default combine state. However it was using
argument 0 for both checks so the if-statement would never be true.
_cogl_pipeline_needs_blending_enabled tries to determine whether each
layer is using the default combine state. However it was using
argument 0 for both checks so the if-statement would never be true.
There are a set of "EvalFlags" that get passed to _cogl_pipeline_hash
that can tweak the semantics of what state is evaluated for hashing but
these flags weren't getting passed via the HashState state structure
so it would be undefined if you would get the correct semantics.
There are a set of "EvalFlags" that get passed to _cogl_pipeline_hash
that can tweak the semantics of what state is evaluated for hashing but
these flags weren't getting passed via the HashState state structure
so it would be undefined if you would get the correct semantics.
According to 9cc9033347 the windows headers #define near as nothing,
and presumable the same is true for 'far' too. Apparently this define is
to improve compatibility with code written for Windows 3.1, so it's good
that people will be able to incorporate such code into their Clutter
applications.
According to 9cc9033347 the windows headers #define near as nothing,
and presumable the same is true for 'far' too. Apparently this define is
to improve compatibility with code written for Windows 3.1, so it's good
that people will be able to incorporate such code into their Clutter
applications.
Since c6493885c3 when building the EGL backend for eglx there was
no fallback in the init_events implementation so the X11 backend init
function would never get called. This was stopping it from receiving
any X events so a lot of things broke. It now just chains up.
