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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
Powered by http://movial.fi
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
