Cairo beginners question

BlitzMax Forums/Brucey's Modules/Cairo beginners question

Kistjes(Posted 2009) [#1]
Hi,

I was pleased to see the possibilities of the cairo module!

Very often I need to recreate the cairo graphic(s) every frame before displaying them on screen. What is the best way of doing so (performance wise)?

* If I only want to change color, blend or alpha I thought it was a good idea to create an image for the filled shape and another image for the stroke. In the main loop I can set the proper color, blend and alpha before drawing each image. Is this clever or overdone?

* If I want to change the shape I need to create the cairo image and load it into a TImage every frame. Or can I clear the existing TCairo instance (to a transparent layer)? Or...?


I included an example of the two-images-per-shape method:




Brucey(Posted 2009) [#2]
Very nice demo :-)

I suppose the biggest issue you might have with Cairo, is that it is not really designed for realtime drawing. Although it has improved significantly since I first wrapped it. (I think this comes from its integration into GTK and Mozilla)
Also, a native OpenGL backend is not currently feasible - if it were, I would definitely have that as an option!

for 1, I think, if you are not intending on changing the shape too often, it's a reasonably good way to cache it. Certainly much faster than recreating it. But, if you need to scale UP, you would get some artifacting. (scaling down of course wouldn't have that problem).

Not too sure about your second question.
You might get away with calling Save(), drawing all your stuff, taking a snapshot of it, then calling Restore() when you want to reset it back to its state before.
Save() and Restore() can be very useful tools - for temporary setting of colours/cap/join etc.


Kistjes(Posted 2009) [#3]
Thank you for the clear answer. I was afraid you're going to say something like this.
I'll keep Cairo in mind for some impressive, but static, vector drawing ;)


Brucey(Posted 2009) [#4]
Well, it's much faster than it used to be, and you can certainly do some useful things with it.

I suppose it depends how much you want to do with it - realtime.
Driving a whole interface is possible not cpu-effective. But I can see a case where it might fit in to do a little rendering where required.
The "slow" part of the process is obviously having to do everything directly on the pixmap data - and then having to copy that data back into VRAM. But if you keep things reasonable it can work.

One other nice thing (if you are into that) is that you can change the "backend" and have it render the using the same code, to a PDF, for example.

Anyhoo :-)