[cairo] Re: drawlist type functionality?

[Mike Emmel]

On Apr 4, 2005 8:31 PM, Jon Smirl <jonsmirl at gmail.com> wrote:
> A draw list implemented on top of Cairo can't be optimized, it is
> better for the list to exist in the layers below Cairo.
> 
I think it can start with a high level naive implementation that then handed 
back through a lower api that "compiles" to primitives for the target backend.

Also the advantage of this api is some higher level management of
groups of drawing routines this is above/outside of cairo I think ?

> For example you might implement CarioBeginList/CairoEndList(). This
> would enable list support in the various backends.
> 
> For OpenGL this would directly translate into an OpenGL display list.
> OpenGL display lists can be cached in the client when rendering
> remotely. They can also get compiled into card specfic commands and
> stored on the graphics card. Another optimization is that all textures
> in the list may be converted to match the native hardware format.
> 
> For other backends you might want to build a generic list
> implementation library that the backends could use if they don't have
> built-in display list support like OpenGL.
> 
Right..
> It is really important to consider hardware optimization when
> designing things like this. It is very easy to design features that
> can't be accelerated on existing hardware.
> 
That says to me there are two api's one on top of cairo for the most
part that uses the public api and a second "engine api" that the
engine uses to accelerate the draw lists for various backends  ?
Thus there is and additional api between the backends and the engine.
I assumed that the engine would break down or decompose the requests
into some internal format  and yes its probably backend specific.
But it would be similar to the current cairo backends ?
OpenGL would be the one I would think that has the closest api and
would want the greatest control.

Michael Emmel
> --
> Jon Smirl
> jonsmirl at gmail.com
>