it's not about the conversion itself, but the data.
libcairo + librsvg == data galore.
As for counting cairo out, sure not. But use it for specific scope.
Indeed, its a standard in my GUI toolkit at this point .. soon as I get a neo in my hands, I'll have a go at getting it rendering a small SVG suite as soon as I can ..
However, even UIs being scalable, they're basically described by pixmaps. It's insane to calculate a gradient on real time just to get a smooth blend: using a gradient pixmap and maybe using (even smooth) scaling would look as good, but use less CPU. Same for rounded corners, you can have a path to describe it, but a smart blit algorithm would be as fast.
Its nicer to render vectors to your destination buffer/pix format than do pixel processing from a bitmap file format, imho. The extra boot-up time (to render SVG as needed) is a matter of taste, of course, but I never count out the idea of a display-list render loop until I've tried running it on targetted hardware ..
BTW, evas have a cairo backend, so you can mix both if required. Other backends, like xrender, opengl, fb and directfb are supported as well.
Be nice to do the SDL dance too, because there are some fantastic SDL apps in the world ..
j. _______________________________________________ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
