[cairo] Background image

[Daniel Amelang]

On 2/19/07, Olivier Jolet <olivier.jolet at skynet.be> wrote:
> > No, I don't have problem with this method. But the display is very
> slow
> > (zoom in & out with the scroll mouse button)
>
> ...
>
> Ok, I will not use glitz backend... I still use native (Xlib) surfaces.
> The problem is that I need to draw many (between 10k 500k) lines,
> polygones and arcs (fill or not), and I don't get a nice speedup. (I
> tried to reduce the number of calls to cairo_stroke). I noticed that the
> worst performance came from the build of arcs.
> I'm going to try another method that consist in drawing the arcs I need
> with specifics sizes in another surface and copy them with a color mask
> instead of building them at each call.

The code you provided is basically a really small graphics interpreter
w/out any input data. So it's hard to give you really meaningful
feedback on it. Ideally, you would provide code + data so that one
could actually execute the program and run a profilier on it. That
said, I don't see anything unusually wrong (from a performance point
of view) from the code you provided.

Now, you have a bunch of calls to getINT16 and getFCT inbetween calls
to cairo functions. We can't see what is going on in those functions
(no code provided), so there's always the possibility that those calls
are slowing things down. Again, running a profiler would answer than
question pretty well.

Also, you mentioned that you expect to draw (in real time) possibliy
500k lines/arcs/rects. That's a lot of drawing. And the user probably
isn't going to actually be able to see 500k primitives at one time,
especially when there's some zooming going on. So, you could probably
benifit from some clipping, if you aren't doing it already. Even your
own application-level clipping would probably help in reducing the
number of cairo calls.

One more thing: if your scene is static, you could first draw the
whole thing at various scales and them zoom between the cached
renderings at run time. Sorta like a roll-your-own mipmapping thing.

Dan