Just like GLIB_DEPRECATED and GLIB_DEPRECATED_FOR, Clutter should have
its own wrappers for G_DEPRECATED and G_DEPRECATED_FOR, to allow opting
out of deprecation warnings.
Deprecation warnings are enabled by default, now, even when building
Clutter.
Keeping the backing Cairo surface of a CairoTexture canvas in sync with
the actor's allocation is tedious and prone to mistakes. We can
definitely do better by simply exposing a property that does the surface
resize and invalidation automagically on ::allocate.
The current "create context/draw/destroy context" pattern presents
various problems. The first issue is that it defers memory management to
the caller of the create() or create_region() methods, which makes
bookkeeping of the cairo_t* harder for language bindings and third party
libraries. The second issue is that, while it's easier for
draw-and-forget texturs, this API is needlessly complicated for contents
that have to change programmatically - and it introduces constraints
like calling the drawing code explicitly after a surface resize (e.g.
inside an allocate() implementation).
By using a signal-based approach we can make the CairoTexture actor
behave like other actors, and like other libraries using Cairo as their
2D drawing API.
The semantics of the newly-introduced ::draw signal are the same as the
one used by GTK+:
- the signal is emitted on invalidation;
- the cairo_t* context is owned by the actor;
- it is safe to have multiple callbacks attached to the same
signal, to allow composition;
- the cairo_t* is already clipped to the invalidated area, so
that Cairo can discard geometry immediately before we upload
the texture data.
There are possible future improvements, like coalescing multiple
invalidations inside regions, and performing clipped draws during
the paint cycle; we could even perform clipped redraws if we know the
extent of the invalidated area.
It stands to reason that any piece of code using Cairo and Cogl at the
same time, and dealing with texture data, will want to use the same
logic Clutter uses to determine the compatible pixel format between the
two.
https://bugzilla.gnome.org/show_bug.cgi?id=647875
By using a new signal, ::create-surface (width, height), it should be
possible for third party code and sub-classes to override the default
surface creation code in CairoSurface.
This commit takes a bit of the patch from:
http://bugzilla.clutter-project.org/show_bug.cgi?id=1878
which cleans up CairoTexture; the idea, mutuated from that bug, is that
the CairoTexture actor checks whether the surface it has it's an image
one, and in that case it uses a Cogl texture as the backing store. In
case the surface is not an image one we assume that the surface itself
has some way of updating the GL state and flush the surface.
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
Document that repeated calls to clutter_cairo_texture_create()
continue drawing on the same cairo_surface_t. Add
clutter_cairo_texture_clear() for when you don't want that behavior.
http://bugzilla.openedhand.com/show_bug.cgi?id=1599
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
The cairo pkg-config is crafted such that #include <cairo.h> should be used.
If building with a private build of cairo installed to a custom prefix
<cairo/cairo.h> can cause an un-intended cairo header to be picked up during
compilation due to /usr/include being in the header search path.
Move the ClutterCairo actor from a separate library to an in-tree
actor.
ClutterCairoTexture is a simple texture subclass that allows you
to retrieve a Cairo context for a private image surface. When the
Cairo context is destroyed it will cause the image surface
contents to be uploaded to a GL texture.
The image surface used is not hardware accelerated.
