[cairo] drawlist type functionality in Cairo
davidr at novell.com
Tue Apr 5 17:49:30 PDT 2005
On Tue, 2005-04-05 at 21:25 +0200, Dirk Schönberger wrote:
> > > 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.
> s/would be needed/would be useful/g
> If you don't use an explicit path reference, but instead just use cairo API
> functions, i.e. cairo_lineto, cairo_moveto, I don't see no other solution
> short of display lists to create drop shadow effects. Ok, alternatively you
> could implement ad hoc display lists in client code.
OK, sorry. I thought we were talking about when an explicit path object
> > 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.
> Ok, this makes it more clean. I agree, if you don't have a global cache, you
> don't need explicit keys.
> However, there remain some problems:
> - what happens if a path is rendered into multiple backends which are all
> "active". Seems like a good bit of cache-trashing to me
It wouldn't be worse than no caching. We could have one cache item per
backend if we like that.
> - when will a cached path data be invalidated?
With only one cache item, the current cache item will be invalidated
when a new one needs to be created. A cache item may exist as long as
the path or pattern object exist and the application is responsible for
destroying it by dropping all references to it.
> - display lists would allow to render multiple paths with multiple patterns
> with a many-to-many relation between them, beside of being able to
> store information which change the global graphic state (set_color,
> set_lne_width, ...). I don't see how you would implement this by using
> purely backend specific cached paths and patterns.
The many-to-many relation between paths and patterns would of course
exist as they are different objects. line_width, cap_style and such
would not be part of the path object and I don't see any point in making
it so, it's easily done in a layer above cairo.
You should know that using OpenGL primitives like lines and polygons for
cairo paths is not a good idea. The quality is not even close to what
cairo is currently producing. So using OpenGL's display lists is not
More information about the cairo