[cairo] Re: drawlist type functionality in Cairo

Mike Emmel mike.emmel at gmail.com
Tue Apr 5 08:57:18 PDT 2005


To sum it up hopefully...

Cairo requirments for a caching backend to support asynchronous drawing model.

1.) The format should allow the application of a affine transform
2.) The format should allow application of a new pattern or fill or
stroke style.
3.) Patterns should be cached.
4.) The backend should control the format of the cache
5.) Cairo should provide a api to select the cache as a target and a
way to retrieve a handle to the compiled format.
6.) ???
7.) Profit  :)

On Apr 5, 2005 10:13 AM, David Reveman <davidr at novell.com> wrote:
> Here's my thoughts on drawlist type functionality in Cairo.
> 
> Using OpenGL display lists with cairo is not a good idea. Cairo requires
> rasterization to intermediate buffers and either we use software
> rasterization, pbuffers and CopyTexSubImage or framebuffer objects this
> can't be compiled into a display list. Glitz is not designed to use
> display lists, display lists are memory inefficient and not what we want
> to use.
> 
> What we should be using are vertex arrays and VBOs. Glitz already
> support this perfectly, we just need to make cairo utilize it.
> 
> I don't think we need a cairo display list or similar at all.
> 
> I think it's all about caching. An application that likes to use a
> pattern more than once shouldn't create a new pattern every time. It
> should create the pattern once, keep a reference to it and use it
> whenever it likes. Backends can be smart and cache this pattern in
> appropriate form. e.g. if you'd create a pattern from an image surface
> and use it draw onto a glitz surface the glitz backend would cache a
> glitz surface in this pattern.
> 
> The same thing applies for paths. If we allow the application to keep a
> reference to a cairo unscaled path, backends would be able to cache
> these path objects as they like. Glitz backend could keep all vertex
> data in a static VBO for optimal performance.
> 
> All we would need in the API is an opaque type for an unscaled path and
> possibly some usage hints which could be used for optionally telling the
> backends how to cache a path or a pattern.
> 
> -David
> 
>



More information about the cairo mailing list