[xinf] Future direction of Xinfinity

[Nicolas Cannasse]

>>a) the classic way (Flash,AGG) draw everything in memory using expensive
>>CPU routines.
> 
> 
> I really want to avoid this approach, which I perhaps didn't make
> clear in my last post. Cairo particularly annoys me in this regard
> because it claims OpenGL support but doesn't really use it for
> anything.

AGG does not claim anything like that. You're just doing the rendering
into some memory buffer than can then be used for any kind of usage
(save on-disk, display on-screen, 3D texturing...). That's the way most
Vector graphics renderers - including Flash - are working. And it works
pretty well for small resolution when there is not too much vector
shapes to render.

>>b) the HW way (commercial libraries only ?) are tesselating vector
>>shapes into triangles that are sent to the GPU (using OpenGL API for
>>example). This take a lot less CPU time but require proper HW support
>>(less usable for embedded devices).
> 
> 
> Yes, this is the way I plan to do it. It's also the way Amanith and, I
> think, Shiva work too so this approach is certainly not limited to
> commercial libraries.

Nice. I haven't followed new libraries for some time now. What is
important for me when I choose a library is : clean API and readable -
lightweight - source code. Usually when a library have a few MB of
sources it means it's already bloated. The whole Neko VM for example is
only 210KB (+140KB of standard library sources).

> That said, there will definitely need to be an alternative backend for
> embedded devices, and here Cairo and AGG become viable again.

Cairo seems like a wrapper around different outputs, which IMHO can
result in a bloated API if not done correctly. I have quickly looked at
it but didn't choose it as vector engine when I was working on the topic.

Nicolas