<div>On 3/7/07, Daniel Amelang <<a href="mailto:daniel.amelang@gmail.com">daniel.amelang@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On 3/7/07, <a href="mailto:leonid.zolotarev@nokia.com">leonid.zolotarev@nokia.com</a> <<a href="mailto:leonid.zolotarev@nokia.com">leonid.zolotarev@nokia.com</a>> 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.</blockquote><div> 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) </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > 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: > <a href="https://bugs.freedesktop.org/show_bug.cgi?id=10208">https://bugs.freedesktop.org/show_bug.cgi?id=10208</a> First off, do you really have to recomposite at each scroll step? Are</blockquote><div> 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... </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.</blockquote><div> 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... ? </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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?</blockquote><div> 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? </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote><div> 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 :( </div> Br, Oleg <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 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 <a href="mailto:cairo@cairographics.org">cairo@cairographics.org</a> <a href="http://cairographics.org/cgi-bin/mailman/listinfo/cairo"> http://cairographics.org/cgi-bin/mailman/listinfo/cairo</a> </blockquote></div>