Re: Adding image file loading to ClutterImage

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 7 January 2014 21:24, Dominique Bureau <dbureau gmail com> wrote:
> Hello everyone,
>
> I’m currently subclassing ClutterImage for my own need to gain back the
> ability to load image files from the JSON configuration (like
> ClutterTexture, using a “filename” property).
>
> I was wondering if I should work this as a patch for ClutterImage, or do we
> want to stay away from having the pixbuf loader code into Clutter? Any
> suggestions/ideas?

no, I don't want file loading code inside Clutter any more: it's
wrong, and broken, and will inevitably lead to broken behaviour. it
almost always is *not* what you want to use either.

for the ClutterTexture:filename property I already had to punch a hole
in the ClutterScript API to let you set a specific set of base
directories so that you can use a relative path in the JSON
description; that's one of the broken behaviours that creep in once
you go down this route. once you set the ability to load from file,
you have to avoid it blocking, so you add the insanity that is the
threaded loading model inside ClutterTexture, with signals and main
loops, and actors that do not have a size until something spins —
unless you decide to block just until the (threaded) file format
loader gets to the point where the dimensions of the image are
defined. then you need the stream-based, or the GFile-based interface,
so you can load images from a URI. then you want a cache, so you only
load image data from a file only once, which means that each file has
to be kept around so we can check if it's been loaded, except that it
also has to be monitored, in case the file goes away and we need to
drop all copies and notify the scene graph to show something else.
finally, all of this has to interact in a sensible and reliable and
deterministic way, except that the combinatorial explosion of public
entry points has ballooned out of control, and we have ClutterTexture
all over again: a type you cannot subclass because it has a ton of
side-effects and behaviour that you cannot override.

we have a library for loading image data from file, or stream, or
memory buffer, and it's GdkPixbuf. all platforms supported by Clutter
either have GdkPixbuf installed, or themselves have API to load image
data from a file (using different file formats) and put it into a
memory buffer. that's all I am interested in supporting inside the
core of Clutter.

if you want to add a "filename" property to a ClutterContent
implementation so you can use it from ClutterScript, you should have
your own ClutterContent implementation — either via subclassing
ClutterImage, or by creating your own class, with your own semantics
and behaviours that you control.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/