Re: pictures

[Benjamin Otte <otte gnome org>]

On Mon, Feb 14, 2011 at 10:28 PM, Matthias Clasen
<matthias clasen gmail com> wrote:
> - Why does this belong in gdk ?
>
It's in GDK for now because that's where gdk-pixbuf comes from. And as
I'm targetting GTK and didn't want to work on two git checkouts while
playing with it, I stuck it into gdk. Emmanuelle asked about possibly
using it for Clutter. So it's probably useful to split it into its own
package just like we did with gdk-pixbuf. It also depends on how

> - It seems to be somewhat stuck in an uncomfortable place between a 'dumb pixel
>   area' (GdkPixbuf) and a 'smart active image' (resizable, possibly
> animated, draws itself)
>
Could you elaborate on the "uncomfortable"? It seems a rather nice
place to be from my way of looking at things. The only reason why it's
a somewhat ugly place is that conceptually, you're used to think of
images as one of those two examples.

> - How does this relate to cairo surfaces ? If pictures are the one
> true way to pass pixel
>   data to gtk, do we need a picture that wraps cairo surfaces ?
>
Well, a picture that wraps a cairo surface is basically just
boilerplate code (set_surface and get_surface API and implementing the
ref_surface vfunc).
http://git.gnome.org/browse/gtk+/tree/tests/testpicture.c?h=picture
has it at the top. So it's easy to code yourself if you need it. Also,
from my experience with all the rendering things, almost nobody needs
that functionality. People don't use cairo surfaces, they use "the
image loaded from a file" or "the icon". And the code has pictures for
that.

> - Making the pictureloader both be a picture and have a picture seems
> unnecessarily confusing.
>
Yeah, I'm not sure about that API yet. What you want is 2 things:
1) picture_new_from_uri()
2) nonblocking
And picture_new_from_uri() needs to return an object immediately so
you can stuff it into the widget of your choice. You don't want the
typical gio behavior with having to wait until the async callback gets
called and you can call load_finish() to hand you the final image. But
you might care about the resulting image and whether it implements
interfaces like animatable (gif) or resizable/stylable (svg), so you
need to provide a picture and can't just make the loader picture
implement all of these interfaces.
I'm not happy with the API but couldn't come up with a better one. And
I think people want the ability to stuff flickr images by URL into an
iconview without blocking. (I suspect they'd use webkit for that
today?)

Benjamin