Checking offscreen for COGL_INVALID_HANDLE is not sufficient,
as cogl_offscreen_new_with_texture doesn't initialize framebuffer
objects but lets Cogl solve this the lazy way.
cogl_offscreen_new_with_texture will never return COGL_INVALID_HANDLE
anyways.
https://bugzilla.gnome.org/show_bug.cgi?id=764898
Cut down on boilerplate by using the (no longer that) new helper
macros. We don't care about breaking ABI in private libraries, so
use G_DECLARE_FINAL_TYPE even where the class struct used to be
exposed in the header, except for types we inherit from ourselves
(obviously) or where the class exposes any vfuncs (where changes
could affect inheritance in extensions).
They are unused, as we don't use them ourselves and the class is not
exposed to introspection. Drop them to allow defining the type as final
in an upcoming commit.
This ensures that two widgets sharing the same theme node won't trample
on each other's prerendered materials if the actors are of different
sizes. This also tries to be very careful to share as much as possible
during a transition.
This has the side effect that if a widget changes state a bunch of times,
we won't cache every state. Since we expect that state changes are
infrequent and that most cases we'll be able to use the texture cache
to do most of the heavy lifting, this cost is much more insignificant
than rendering a number of different actors with the same theme node
and different sizes.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
Setting up the framebuffers for transitions may fail, in which case
the material used for drawing is left uninitialized, so trying to
access it results in a crash.
Instead bail out in this case, which means that we won't paint
anything during the transition - still, drawing errors are better
than crashes ...
https://bugzilla.gnome.org/show_bug.cgi?id=659676
StWidget reports a paint volume large enough to paint the current
theme node. As CSS transitions also paint the previous theme node,
the reported paint volume may be incorrect, resulting in screen
artifacts when painting outside the reported volume.
Add st_theme_node_transition_get_paint_box() to calculate an allocation
large enough to paint both theme nodes, and use it to report the correct
paint volume during transitions.
https://bugzilla.gnome.org/show_bug.cgi?id=640085
* Make sure all source files have a LGPL copyright header, and standardize
non-standard variations of the header to a common form.
* Check and update all copyright notices.
* Remove 'Written By:' lines. They are universally incomplete and
typically indicate only who started a particular file.
https://bugzilla.gnome.org/show_bug.cgi?id=634550
Switch to using the layer combine constant rather than the material
primary color for representing the opacity of the material; this
avoids triggering a Cogl bug where changing the primary color corrupts
the layer state.
https://bugzilla.gnome.org/show_bug.cgi?id=629616
Add st_theme_node_paint_equal() and use that to do two things:
1) Avoid animating transitions where nothing changes.
2) Copy cached painting state from the old theme node to the new
theme node.
https://bugzilla.gnome.org/show_bug.cgi?id=627083
Creating an FBO may be expensive, so we should avoid the operation
if possible. When transitioning between theme nodes, the widget's
opacity is used to paint to the offscreen textures which are blended
together - this means that the textures have to be recreated each time
the widget's opacity changes. It is much more effective to paint the
textures at full opacity and respect the widget's paint opacity when
blending the textures together.
https://bugzilla.gnome.org/show_bug.cgi?id=627085
The framebuffer setup code can fail, e.g. when the texture used as
color buffer has a height/width of 0. In that case, the call to
cogl_pop_framebuffer() will crash the shell trigger an assert. Add
error checking to fail gracefully.
Our behavior of reversing the animation when the widget's style
changes back to the previous one is sound. On the other hand, when
there's a change to a new style while a transition is active, we
simply cancel the ongoing transition. Updating the transition
correctly so that the new one starts from an intermediate state
is hard.
Nevertheless, if the style changes before any time of the transition
has elapsed, we should do better than the current behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=621140
