[cairo] [Patch] make _color_to_short() use _cairo_fixed_from_double()

Daniel Amelang daniel.amelang at gmail.com
Wed Jan 24 13:01:38 PST 2007

On 1/24/07, Behdad Esfahbod <behdad at behdad.org> wrote:
> On Wed, 2007-01-24 at 19:09 +0200, Jorn Baayen wrote:
> >
> >
> > As we are talking 16 bits of relevant data, I was thinking that
> > whether
> > we round or floor is of little importance (rounding strikes me as more
> > 'right' though, personally). Anyway, as this patch has no measurable
> > performance impact it probably isn't worth dwelling here much longer.
> While the performance impact is ignorable, please take a minute and
> think about it and convince yourself that floor is right.  Think about
> the input and output spaces and how to map evenly.

For archival purposes I figure I should share an experience I had with
improving the performance of the color-related paths in cairo:

Back in Oct 2006 I whipped up a version of _color_to_short that had
the exact same behavior as the current code (floor, not round), but
was much faster on both x86 and ARM. Then I wrote a perf test (I
hadn't yet learned that I should do this first :).

Turns out you have to work _really_ hard to make a perf test that
shows off improvements in the color paths. What wasn't obvious to me
at the time (and is now perfectly clear to me) was that you don't
select very many colors in cairo without doing some sort of drawing
operation between selections. And that drawing operation is almost
always going to be much slower than the color selection. So, until
drawing improves by leaps and bounds, the color code doesn't need any

If anyone does come across a need to speed up the color-related code
paths, let me know. I'm still hoping I can justify the many hours I
put into that code :)


More information about the cairo mailing list