[maemo-developers] [maemo-developers] Cairo benchmarking

[From: Matthew Allum]

Hey;

Though internally cairo is mostly fixed point, its api is floating point -
the 770 ( like most ARM devices ) lacks an FPU and thus any FP operations (
especially with hardfloat ) are slooooowww and really should be avoided.

Also as yet cairo isn't heavily optimised and without any kind of supported
h/w acceleration cairo operations can be very cpu intensive especially on a
relatively large display.

-- Matthew

On 10/27/05, Kalle Vahlman <kalle.vahlman at gmail.com> wrote:
>
> Hola list!
>
> I started to write a little Cairo animation to better introduce myself
> to the wonders of it, and thought I'd do a little Cairo benchmarking
> with it on the 770.
>
> The setup:
>
> Compiled cairo 1.0.2 with vanilla settings, and copied to the device.
> Compiled my demo with -O3
> The device was not the latest HW nor SW, so the results might be a tad
> worse than they are on the current devices. Haven't rerun the
> benchmark yet on newer devices.
>
> The demo:
>
> It consists of:
> - creating a XLib surface from the X window
> - creating image surface for background (only on startup)
> - copying from that to a buffer surface to clear bg when drawing
> - drawing a simple shape with lines and few bezier curves on the buffer
> surface
> - copying the drewn areas to the xlib surface
>
> I don't know if this is the most efficient way to draw with cairo, I
> might be doing something foolish here and slowing down the process
> (please say that I do?-).
>
> The results:
>
> Not that convincing.
>
> I ran the demo with 1, 5 and 10 objects drawn simultaniously, and the
> FPS calculated from those are 5.71, 2.6 and 1.51.
>
> So nowhere near "smooth" animation.
>
> I tried to compile the cairo with the softfloat toolchain in
> scratchbox but that made cairo refuse to draw anything (not sure what
> goes wrong there), although it doesn't crash or complain.
>
> The timings for the last three items in the above list tell that the
> slowest parts are (not suprisingly) the item drawing (0.048s per item
> consistently) and the transferring to the xlib surface (0.099s for 1
> item, 0.115s for 10 items).
>
> Intresting note is that the xlib surface transfer is apparently well
> buffered, and does not grow linearily with the item count. Still the
> initial hit is big enough.
>
> This is of course presented in the context of animation, but I think
> that if you can't do smooth animation (somewhere between 10-15FPS)
> with simple objects, it won't be fast enough for UI either.
>
> The biggest bottleneck seems to be indeed the object drawing (I'd
> guess the beziers are to blame), but I intend to test drawing
> different types of elements once I get the time, plus a better
> profiling of what's taking so long and where.
>
> The test results are attached, as well as the demo (the code is little
> messy and contains excess stuff as it's been "evolving").
>
> --
> Kalle Vahlman, zuh at iki.fi
> Powered by http://movial.fi
>
>
> _______________________________________________
> maemo-developers mailing list
> maemo-developers at maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maemo.org/pipermail/maemo-developers/attachments/20051027/45cd8807/attachment.htm