Re: Speed of Gdk-Pixbuf Vs. GdkRGB

[John Cupitt <john cupitt ng-london org uk>]

Hi again,

David J. Singer wrote:
> On Wednesday 21 April 2004 6:13 pm, John Cupitt wrote:
>
> > They are equivalent (AFAIK). You only need the lower-level stuff if you
> > want to avoid loading the whole image into memory
>
> OK. That's interesting. I kinda assumed GdkRGB would be loads faster 
> because it has a much "lower-level" feel to it...   I was using it to display
> simple (widget-type) animations by manually loading all the frames into memory 
> then calling up each frame using 'gdk_draw_rgb_image' with the required 
> offset.. The prospect of using the built-in animation stuff seems tempting,
> but only if it is *at least* as quick as my current method! :)

Ah OK. I always think in terms of image display widgets (what I've worked on). If you're doing a lot of animation I guess it's different and maybe the lower level stuff would offer savings.

Have you looked at the pixbuf demo?

 gtk+-2.4.0/demos/pixbuf-demo

It animates with scaling and transparency, you might be able to make a simple benchmark out of it too. testpixbuf-scale is rather cool as well.

> > The downside is you must only ever paint in the expose handler.
>
> That's the catch. It's usually far more useful to be able to assemble the backing 
> pixmap piece by piece, then just allow it to get "automatically" updated (as it 
> were) when an expose event occurs...  So I guess in this case I need to 
> stick to my old method of doing it?  Right?

I guess you'll need to experiment :-( I have simple animations in my application (rubber-band lines are drawn with crawling dashes, selection outlines are drawn with a 3D appearance and slide over the image and over each other as you drag, and so on) and they all work like this:

- event occurs, for example a timer callback or a mouse action
- queue an expose for the current position of the object
- update the object position and state
- queue an expose for the new object position

The expose handler works like this:

- loop for all dirty rects
- set the clip to the rect outline
- loop for the set of screen objects which touch this rect, in Z order
- ask object to repaint

So updating the internal model and painting it are decoupled. Sorry if this is obvious or unclear.

John