pictures

[Benjamin Otte <otte gnome org>]

Hey,

I've pushed a new branch "picture" to the gtk repository. It contains
an implementation of an idea I've toyed with in my mind for a while.
It's of course not finished yet, but already works very well and more
importantly is the simple API that I had envisioned. So I'd like to
get it merged into GTK 3.2 if nothing unforseen happens.

For now, I'm interested in high-level review of the idea. Things like
"This whole idea is stupid because ...", "I would change the API so
that ...", "If you did this, we could also use it for ...", "How do
you intend to solve ..." or "I think you should not name it picture
but ..." are what interest me.

So what exactly is a Picture?

That's the hardest thing for me to explain. The short answer: It's the
stuff you put into a GtkImage. The long answer: It's a new way to
describe pixel areas (I on purpose don't use the word "image" here as
that makes people think of PNGs and JPEGs) as used in GTK. It does not
handle input at all. It is meant to replace GdkPixbuf completely.

If you want to play with the code, there is a tests/testpicture
example that showcases the different picture types.

The header defining GdkPicture can be found at
http://git.gnome.org/browse/gtk+/tree/gdk/gdkpicture.h?h=picture
It will tell you that a picture has
- a size (width and height)
- a way to draw it to a cairo context
- a way to tell you its contents changed
- a way to tell you it got resized
and that is all a basic picture has.

The three important changes to GdkPixbuf (besides using Cairo instead
of some weird pixel format) to me are:
1) It hides unnecessary things
By not exposing the pixels, the internal storage format etc, code can
both implement optimizations (you are for example free to store your
data as a GL texture if that makes things go faster) and be a lot more
flexible (you could have a subclass that does not store any pixels but
actually renders text).
2) It can change
By emitting signals whenever things change (both contents and size can
change), you can implement rather complex pictures that adapt to the
environment and change with it. For example GtkNamedPicture - see
http://git.gnome.org/browse/gtk+/tree/gtk/gtkstockpicture.c?h=picture
- represents a named icon from the icon theme and automatically
updates when the icon theme changes. There's no need to duplicate all
this theme-changing code into every widget that wants to display
icons.
Also, you can invent very complex pictures and have them work in all
widgets automagically. People on IRC were quite excited about a
GtkThumbnail picture subclass that displays the thumbnail for a given
file or if it doesn't exist yet, triggers its generation and displays
the regular file icon until the thumbnail is available at which point
it updates.
3) It allows nesting
A picture subclass can display one of multiple different pictures
based on its state (like the examples above) without having to care
about hairy code like asynchronously loading files, you just display
the picture that does the loading. This reduces code complexity a lot.

The code so far does everything that's necessary to replace the
internals of GtkImage with pictures. In fact, the latest commits do
that and you can see the result at
http://git.gnome.org/browse/gtk+/tree/gtk/gtkimage.c?h=picture - it's
not very pretty though because it's API-compatible so has to keep all
the old properties.

I intend to include some more APIs (as interfaces) in the coming weeks
that expose more common functionality (animations and user-resizable
pictures) in the coming week and will keep you posted about those, but
for now this is the state that I'd like to talk about.
Comments?

Benjamin