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
Cairo stores the image data in ARGB native byte order so we need to
upload this as BGRA on little endian architectures and ARGB on big
endian. ClutterTexture doesn't currently expose any flags to describe
ARGB format so until we can fix the Clutter API it now uses the Cogl
API directly.
Instead of unpremultiplying the Cairo data, pass it directly to Cogl
in premultiplied form; we now *prefer* premultiplied data.
http://bugzilla.openedhand.com/show_bug.cgi?id=1406
Signed-off-by: Robert Bragg <robert@linux.intel.com>
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>
With the recent change to internal floating point values, ClutterUnit
has become a redundant type, defined to be a float. All integer entry
points are being internally converted to floating point values to be
passed to the GL pipeline with the least amount of conversion.
ClutterUnit is thus exposed as just a "pixel with fractionary bits",
and not -- as users might think -- as generic, resolution and device
independent units. not that it was the case, but a definitive amount
of people was convinced it did provide this "feature", and was flummoxed
about the mere existence of this type.
So, having ClutterUnit exposed in the public API doubles the entry
points and has the following disadvantages:
- we have to maintain twice the amount of entry points in ClutterActor
- we still do an integer-to-float implicit conversion
- we introduce a weird impedance between pixels and "pixels with
fractionary bits"
- language bindings will have to choose what to bind, and resort
to manually overriding the API
+ *except* for language bindings based on GObject-Introspection, as
they cannot do manual overrides, thus will replicate the entire
set of entry points
For these reason, we should coalesces every Actor entry point for
pixels and for ClutterUnit into a single entry point taking a float,
like:
void clutter_actor_set_x (ClutterActor *self,
gfloat x);
void clutter_actor_get_size (ClutterActor *self,
gfloat *width,
gfloat *height);
gfloat clutter_actor_get_height (ClutterActor *self);
etc.
The issues I have identified are:
- we'll have a two cases of compiler warnings:
- printf() format of the return values from %d to %f
- clutter_actor_get_size() taking floats instead of unsigned ints
- we'll have a problem with varargs when passing an integer instead
of a floating point value, except on 64bit platforms where the
size of a float is the same as the size of an int
To be clear: the *intent* of the API should not change -- we still use
pixels everywhere -- but:
- we remove ambiguity in the API with regard to pixels and units
- we remove entry points we get to maintain for the whole 1.0
version of the API
- we make things simpler to bind for both manual language bindings
and automatic (gobject-introspection based) ones
- we have the simplest API possible while still exposing the
capabilities of the underlying GL implementation
It is possible to change the surface size after construction with
clutter_cairo_texture_set_surface_size so it doesn't seem right to
restrict changing the properties.
clutter_cairo_texture_resize_surface_internal is called in a handler
for the notify signal. It is called there rather than directly in the
set_property handler so that changing both properties in a single
g_object_set will only cause one resize. The constructed override is
no longer needed.
resize_surface_internal will now bail out if the size of the surface
is already the right size.
The current CairoTexture can be created with a surface size of 0
by 0 pixels, but a warning will be printed.
Worse, the surface can be resized to be 0 by 0 pixels without a
warning. The :surface-width and :surface-height properties accept
a minimum value of 0, and not check is performed on either the
constructor or set_surface_size() parameters to enforce the "greater
than zero" rule.
The correct and consistent behaviour is to allow a 0 by 0 pixels
surface size everywhere; inside surface_resize_internal(), the
current surface will be destroyed and if either :surface-width or
:surface-height are set to 0, the resizing terminates.
Attempting to create a Cairo context from a CairoTexture with
either :surface-width or :surface-height set to 0 will result in
a warning.
This allows:
- creating a CairoTexture with :surface-width or :surface-height
set to zero and delaying the surface resize at a later point;
- resizing the surface to 0 by 0 pixels to destroy the image
surface used internally;
- increase the consistency in the usage of CairoTexture.
Fix the CairoTexture description, and some of the comments inside
the code, especially with regards to the alpha channel unpremultiplication
that we have to perform each time we upload the image surface to
GL.
If you create a Cairo context in the middle of a paint run and then
you destroy it, the CairoTexture will have to upload the contents of
the image surface to the GL pipeline. This usually leads to slow
downs and general performance degradation.
ClutterCairoTexture will warn to the console if Clutter has been
compiled with the debug messages and if create() or create_region()
are called while an actor is in the middle of a paint.
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.
