[cairo] Reduce number of floating point operations

[Daniel Amelang]

On 11/21/06, Behdad Esfahbod <behdad at behdad.org> wrote:
> On Tue, 2006-11-21 at 15:41 -0500, Daniel Amelang wrote:
> >
> > 4) Use a matrix state flag as a bit flag for is_identity,
> > is_translation, etc. The code is now _very_ ugly, very tricky (did you
> > cover all possible state transitions?), and isn't any faster on any
> > benchmark that I have. Reason why is that is_translation isn't called
> > that much at all (assuming my version of the transform glyphs patch)
> > compared to is_identity, so this additional caching doesn't get you
> > very far.
>
> Cannot tell without seeing your code, but I guess you didn't do it like
> I had in mind.  In my plan, user (that is, rest of cairo) shouldn't care
> about is_identity and is_translation at all.  The very matrix operations
> will use them.  That is, your patch probably didn't speed up this:
>
> void
> _cairo_gstate_user_to_backend (cairo_gstate_t *gstate, double *x, double *y)
> {
>     cairo_matrix_transform_point (&gstate->ctm, x, y);
>     cairo_matrix_transform_point (&gstate->target->device_transform, x, y);
> }
>
> In my plan, cairo_matrix_transform_point will first examine the
> is_identity flag and return immediately if it's set.  Is that what you
> did?  This way, it will not clutter the entire code base.

Yes, that's what I did. I wasn't clear about what part of the code got
ugly. I meant to say that it was just cairo-matrix that got real ugly.

Notice though, that I said that I _do_ recommend the is_identity flag.
I _don't_ recommend creating a general bit-field flag that tries to
keep track of more than the identity state. That's where the ugliness
came from (inside cairo-matrix, trying to maintain/use the flag
correctly) with no added benefit. So, I am for the kind of
optimization that you point out, I just haven't gotten around to it
yet. Right now, I'm trying to stay driven by my profile output, and it
wasn't until today that _cairo_gstate_user_to_backend made it close
enough to the top that I noticed it.

I am gathering together several small patches that (hopefully) I'll
submit in the next day or so that do very small optimizations like the
one you point out (basically checking for identity or transform and
skipping certain parts of the code). After all those are applied, I
expect is_identity and/or is_transform to show up towards the top of
the profile (they don't yet), and at that point I'll submit my
is_identity flag patch (it's done already, it just doesn't provide any
meaningful speedup right now).

Dan