Commit Graph

17 Commits

Author SHA1 Message Date
Neil Roberts
16680c74f3 Revert "clutter-cairo-texture: Use the new cogl_pixel_buffer API"
This reverts commit 716ec82db8.

The Cogl pixel buffer API currently has problems if an atlas texture
is created or the format needs to be converted. The atlas problem
doesn't currently show because the atlas rejects BGR textures anyway
but we may want to change this soon. The problem with format
conversion would happen under GLES because that does not support BGR
textures at all so Cogl has to do the conversion. However it doesn't
currently show either because GLES has no support for buffer objects
anyway.

It's also questionable whether the patch would give any performance
benefit because Cairo needs read/write access which implies the buffer
can't be put in write-optimised memory.

Conflicts:

	clutter/clutter-cairo-texture.c

http://bugzilla.openedhand.com/show_bug.cgi?id=1982
2010-05-10 16:17:32 +01:00
Neil Roberts
493041c505 clutter-cairo-texture: Fix destroying the old texture
In clutter_cairo_texture_create_region it tries to destroy the old
texture before mapping the PBO by setting the texture on the first
layer of the material to COGL_INVALID_HANDLE. However it was using the
material API incorrectly so it ended up showing a warning and doing
nothing.
2010-05-07 18:28:46 +01:00
Neil Roberts
716ec82db8 clutter-cairo-texture: Use the new cogl_pixel_buffer API
ClutterCairoTexture now stores the surface image data in a Cogl pixel
buffer object. When clutter_cairo_texture_create is called the buffer
is mapped and a new Cairo surface is created to render directly to the
PBO. When the surface is destroyed the buffer is unmapped and a Cogl
texture is recreated from the buffer. This should enable slightly
faster uploads when using Cairo because it avoids having to copy the
surface data to the texture.

http://bugzilla.openedhand.com/show_bug.cgi?id=1982

Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
2010-04-16 13:19:57 +01:00
Emmanuele Bassi
79acb088e7 Remove mentions of the FSF address
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
2010-03-01 12:56:10 +00:00
Neil Roberts
f95f4ba3cb [ClutterCairoTexture] Use the right component ordering when uploading data
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.
2009-06-15 12:41:13 +01:00
Emmanuele Bassi
c6b4ea8b44 [cairo-texture] Clean up and whitespace fixes
Simple clean up of the CairoTexture to remove unneeded checks,
redundant variables and white space.
2009-06-15 11:50:23 +01:00
Owen W. Taylor
1e5b5d10c5 Don't unpremultiply Cairo data
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>
2009-06-11 14:17:52 +01:00
Emmanuele Bassi
f8f54989be Merge commit 'origin/master' into 1.0-integration
Conflicts:
	clutter/clutter-texture.c
	clutter/cogl/gl/cogl-fbo.c
2009-05-20 16:49:22 +01:00
Dan Winship
1c6580afd6 [cairo-texture] Document redrawing behavior
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>
2009-05-14 15:53:59 +01:00
Emmanuele Bassi
d6d208da7d Remove Units from the public API
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
2009-05-06 16:44:47 +01:00
Emmanuele Bassi
c93cd4a096 [docs] Documentation fixes for CairoTexture
Sync up the arguments name inside the gtk-doc annotations with their
name inside the function declaration in the header file.
2008-12-19 17:48:30 +00:00
Neil Roberts
64de0411ea [cairo-texture] Remove the construct only restriction on surface size
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.
2008-12-19 15:35:14 +00:00
Emmanuele Bassi
e130e0c9b3 [cairo-texture] Silently discard 0x0 surfaces
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.
2008-12-17 15:58:11 +00:00
Emmanuele Bassi
0e1a3c2124 Warn instead of returning in the IN_PAINT check
It's conceivable that a warning should be deemed enough, instead
of just returning a NULL cairo_t when creating a context for the
CairoTexture actor.
2008-12-12 11:42:16 +00:00
Emmanuele Bassi
4d34872dea Small documentation fixes
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.
2008-12-11 15:51:24 +00:00
Emmanuele Bassi
cf9dea7cf6 Print a warning when creating a cairo_t while painting
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.
2008-12-11 15:48:43 +00:00
Emmanuele Bassi
e934ad03ca Add ClutterCairoTexture
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.
2008-12-11 15:34:47 +00:00