[cairo] Re: Cairo performance issues.

[Daniel Amelang]

On 3/7/07, Andrey Petrov <andrey.petrov at gmail.com> wrote:
> On 3/7/07, Oleg Romashin <romaxa at gmail.com> wrote:
> >
> > Yep!,  now we are trying to do some workaround for it.... where it should
> be done? in cairo_image_surface? or at least in cairo...., xlib... ?
>
> Our original guess was that since Cairo and xlib surfaces actually keep the
> image entities on the server side, it would be easy/reasonable to put the
> caching logic there. However it turned out surfaces are quite simple and
> atomic and probably best left alone not worrying about caches.
>
> The images we are talking about do not change positions to each another at
> all (at least in the usecase we are interested in). Therefore I think it is
> purely Cairo client's problem, and we could create a large surface and just
> scroll it (as opposed to create small one with size of the screen, and then
> redo it on every scroll). The problem with this is that we probably will be
> wasting a lot of memory. Perhaps Cairo's client is better to do all the
> expensive alpha-compositions once, cache them (they are static), and put
> these cached surfaces on the frame being rendered.

That's the idea.

>
> So unless Cairo has plans to add some sort of a "super surface" entity which
> would take care of smaller surfaces and provide higher-level functionality
> (scrolling, zooming, ...) I think we should stick to caching on Cairo
> client's side.

No, no plans for a "super surface" (at least that's my understanding).
This level of functionality is meant to be above cairo, like in a
canvas or a UI widget.

Dan