[cairo] Re: Cairo performance issues.

[Oleg Romashin]

On 3/7/07, Daniel Amelang <daniel.amelang at gmail.com> wrote:
>
> On 3/7/07, leonid.zolotarev at nokia.com <leonid.zolotarev at nokia.com> wrote:
> > Hello Daniel,
>
> Hello Leonid, I hope you don't mind if we take this to the cairo list,
> as there's nothing about your questions that are specific to me. Also,
> it would be advantageous to get other's help on this, too. And others
> might benefit from the answer given.
>
> > I work for Maemo project and currently we are suffering from some severe
> > performance issues related to Cairo library.
> > We manage to identify two most severe issues which affect the Cairo
> > performance on Maemo platform:
> >
> > 1. 'cairo_xlib_surface_backend - paint' function implementation is
> missing
> > and Cairo does composite fallback for each paint operation because of
> that.
>
> This is a red herring. The fact that the xlib surface doesn't
> implement "paint" does _not_ mean that it falls back to pixman
> compositing. The actual compositing is done by the surface's
> composite_trapezoids function, which _is_ implemented by the xlib
> surface. So, nothing to worry about here, really.


cairo-xlib-surface.c
:1628->_cairo_xlib_surface_composite_trapezoids->XRenderComposite
Actually all our problems in non optimized  XRenderComposite, ..... :(,
it is related to our 16 bit color format.....,
and we have no processor MMX support, that can help in fbComposite
functionality...

Even if it works with _cairo_xlib_surface_composite_trapezoids, we probably
still using slow  XRenderComposite... for Images with 32/24 color depth
(Images - our main problem)

> 2. Cairo does not support 16 bit color bitmaps natively and composite
> > operation is very slow because it shall convert from 32/24 to 16 all the
> > time.
> > You can find more details on these issues from the following bug report:
> > https://bugs.freedesktop.org/show_bug.cgi?id=10208
>
> First off, do you really have to recomposite at each scroll step? Are


No, we don't, but cairo doing Xrender(pixman)Composite for each scrolling
step, if  our visible surface contain any Images with alpha channel...  even
without alpha it should to do Composite operation from 24 -> 16...

the two layers that are composited together changing position relative
> to one another? If not, try caching the results of the compositing
> onto one surface and just scroll that surface.


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... ?

Now, assuming you do have to recomposite at each scroll step, you can
> try making the two surfaces of the same type (it looks like you're
> mixing an image surface with an xlib one, is that right?


maybe, destination surface depth, defined according to our real device
depth...
probably we can create destination surface with the same (fake) depth, and
make composite operations more simple?

Or are you
> using the deprecated CAIRO_FORMAT_RGB16_565 format?).
>
> In other words, try creating two image surfaces and doing your
> compositing on those. Or, turn your image into an xlib surface (this
> is the "right" thing to do, BTW), so you have two xlib surfaces and
> then cairo will push the compositing down into the (theoretically
> optimized) X Render implementation for the device.


Our Xrender composite implementation in our xserver - exactly the same  as
in pixman->fbcompose.c....
and our XrenderComposite operations works with the same CPU usage, but on
xserver side :(


Br, Oleg

> Could you, please, help us to resolve at least the first issue because
> this
> > is something that affect the Cairo performance most of all?
> >
> > I'd also appreciate if you provide us with some guidelines on the second
> > issue as well.
>
> Hope that helps.
>
> >
> > Regards,
> > Leonid.
>
> Dan
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/cairo/attachments/20070307/a0dbe985/attachment.html