[cairo] Speedup _cairo_matrix_to_pixman_matrix

[Carl Worth]

On Tue, 21 Nov 2006 12:16:44 -0800, "Daniel Amelang" wrote:
> Ok, after rounding and glyph transforming dropped off the softfloat
> profile, _cairo_fixed_from_double showed up again (even with the new
> optimization). Most of these calls came from
> _cairo_matrix_to_pixman_matrix, and luckly, most of the time, the
> matrix being converted was an identity matrix, so we can easily solve
> this one by adding a quick check for an identity matrix, and do a fast
> memcpy from a template pixman identity matrix to perform the
> conversion.

Lovely stuff, Daniel! All three patchsets look very nice and I'll go
through and land these right away. Well done!

> Again, I need someone with a Nokia 770 to perform the real test.

I'll report some numbers from mine here. And on another note, Last
Friday I visited OSDL and delivered a 770 that had taken a rather
circuitous route to get from Nokia to Bryce at OSDL. I helped walk
Bryce through getting scratchbox installed and getting a usbnet
connection to the device. So hopefully that will be coming online now
and we'll be able to start seeing performance reports from it on a
regular basis as commits land in cairo's repository.

Bryce has even said it would be easy to convince crucible to track
side branches so we could conceivably use that support to do
performance testing of stuff like this even before it lands in cairo's
main repository.

> On a side note, I have laying around a version of
> _cairo_fixed_from_double doesn't have any FP operations at all. Once I
> clean it up, I'll submit the patch. Thing is, it slows down systems
> that _do_ have a FPU, so we''ll have to come up with some sort of
> --avoid-fp configure flag to enable paths that run faster on FP
> crippled systems, but slower on those that have an FPU. Either way,
> it's nice to get _cairo_fixed_from_double entirely off FP, and thus
> far away from the top of any profile on softfloat.

Yes, it might be time for a flag like that soon. We might end up
wanting something similar for the intersection code in the tessellator
(since floating-point can actually be faster than integer operations
on some modern processors).

And there might be other fine-tuning options we come up with later
that embedded systems could use, (such as smaller limits on the amount
of memory used for glyph caches, etc.). Though, the glyph cache system
should be improved a lot first anyway, (like actually having a
size-based limit, and doing random removal across all fonts, etc.).

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20061121/daaf5167/attachment.pgp