[cairo] Re: Lander Game

Carl Worth cworth at cworth.org
Fri Jan 26 09:54:16 PST 2007

On Fri, 26 Jan 2007 09:53:56 +0000, "Alex Mac" wrote:
> > without --native-surfaces: 70 fps (python: 50% CPU, X: 40% CPU)
> >   with --natives-surfaces: 80 fps (python: 50% CPU, X: 15% CPU)
> the difference is not as noticeable for me, maybe thats just the
> effect of a faster pc... since both you and thomas have better
> performance with xlib surfaces I'll make that the default in future

Do you have an old X server running that doesn't support the Render
extension or something? That kind of thing could result in transfers
back and forth from video to main memory, (that is, taking an extra
hit compared to just using software compositing in main memory in the
first place and then transferring).

I've also heard some reports of supposed "RenderAccel" features in
some X drivers (nvidia perhaps?) actually resulting in a net
slowdown. This could be a similar effect, (unsupported operations
causing _horribly_ slow transfers from video memory, for example).

Meanwhile, as to the jerkiness, your current application appears to be
just drawing as much as possible as fast as possible. While that's
fine for producing fps numbers that can be useful for benchmarking,
it's definitely not what you want for having a smooth experience, (you
can't really expect the OS to let your CPU-hogging process have the CPU
all the time). So pick a framerate that you'd like, (definitely
doesn't have to be faster than monitors refresh nor humans can
perceive), and don't draw faster than that. That should provide a
smooth experience with your current code.

> yeah, watching the little gnome-panel cpu thingy I can see it spike
> whenever I press a button :)
> So lets say I rasterise some different sized circles at the start how
> would I then composite them with different colours? Does cairo do
> masking or would that be too slow? should I create a doughnut shaped
> path rather than try stroking a circle?

If you did some frame-rate limiting I don't think you'll actually need
to throw any more raster caching at this. (And by the way, I think all
this painful, extra code you've added for caching shows why it would
be nice to have a canvas layer that actually did stuff like this---I
was surprised when I played with goocanvas to not find any support for
caching things like this.)

But, yes, cairo does have a mask operation. What you would do is to
create a CONTENT_ALPHA similar surface, (or an FORMAT_A8 image
surface), and then just do your stroke to it. Then later you could set
the source color (with the alpha you want for your fading out) with
set_source_rgba and then just call cairo_mask_surface with your cached

Conceptually, that masking is exactly the same operation that's
happening when you're calling cairo_stroke anyway. So, really this
should only be faster, (since you won't have cairo doing any
tessellation to compute the mask). So if you do try this and you don't
see any big speedup, please let us know as that would suggest there
are some broken code paths somewhere that should be easy to make

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070126/9bca9099/attachment.pgp

More information about the cairo mailing list