[cairo] drawlist type functionality in Cairo

[David Reveman]

On Tue, 2005-04-05 at 16:15 +0200, dirk.schoenberger at sz-online.de wrote:
> > 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 believe drawlists would be needed for the following two uses
> 
> - complex drop shadows, where the same path is rendered multiple times

I don't see why.

> - "vector fill pattern", where the fill area is filled with (multiple)
> calls to the rendering API.

Cairo can't really do vector fill patterns yet, but I think the proposed
interface [1] would work quite well with the path and pattern caching
I'm suggesting.

[1]
http://lists.freedesktop.org/archives/cairo/2005-February/003050.html

> 
> It should be possible to implement this with cached references to a
> pattern, but this sound not really "natural" to me.
> Additionally, such a vector fill pattern could consist out of multiple
> sub-patchs which are rendered differently, so it is possibly not enough to
> store one path only.
> 
> > 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.
> 
> A cache implies that you have a key and a value. How do you want to cache
> path which is created dynamically with calls to cairo, but which is not
> given a key / name? You could build some kind of "checksum" out of
> primitives, the path is built from, but I don't really think this is a
> good solution.

To me a cache doesn't necessarily have to do with keys and values, just
that something is stored in a more appropriate way or place for being
used again. But I don't know, maybe I'm wrong, maybe a better
description of what I'm talking about here is "backend specific storage"
of paths and patterns.

This backend specific storage would always be attached to the path
object itself. I'm not suggesting some sort of global cache.

-David