[cairo] _cairo_lround (and effects on positioning of text)

[Carl Worth]

On Tue, 21 Nov 2006 11:27:44 -0800, "Daniel Amelang" wrote:
> i = (int) floor (d + 0.5);
>
> Basically, this is a popular idiom for rounding a double to an int.
> Unfortunately, it suffers from the same slowdown that
> _cairo_fixed_from_double did, especially when there is no FPU.
> Luckily, we can apply the same magic number approach and get a nice
> speedup. So I created the function _cairo_lround and replaced all
> instances of this idiom with a call to it. I called it _cairo_lround
> because lround has the closest sematics to what we want, with the
> difference being that _cairo_lround is much faster that lround, and
> _cairo_lround uses banker's rounding.

So I've got cairo-perf results coming from the three patchsets on the
n770 now, (cairo-perf sure takes a long time there---maybe we should
eliminate some redundancy in the perf suite to make it run faster). On
my x86 it seems only faster, (perhaps as much as 1.2x faster which
isn't so bad considering this isn't the platform being targeted at
all).

I also ran the regression tests on the whole series, (and including
Joonas' improvements to the tessellator as well). All looked good
there except for some failures of the text-specific aspects of 4
tests, (clip-operator, operator-clear, operator-source, and
unbounded-operator), where the text portions have move up by one
pixel.

I bisected that down to this patch, (which was not too surprising),
and verified that indeed these tests are all placing text at a y value
of N.5 (also not surprising given the above description of the
behavior).

When we did the _cairo_fixed_from_double optimization and switched to
banker's rounding for that we said it definitely didn't matter since
it's only affecting a coordinate on the sub-pixel grid, (which is
already more fine than we really need). But with this patch, we're
starting to change some things at the pixel level, and I'm not nearly
as comfortable with that.

I suppose it's "only" text that's going to be affected by this, (since
all geometry rendering already support sub-pixel positioning so won't
have any pixel-level rounding due to _cairo_lround). And the problem
with text is that we don't support sub-pixel positioning, so we do
have pixel-level rounding happening there.

So, do we care that this patch might move some text around by a pixel
compared to where it was drawn before? One argument might be that
since we don't support sub-pixel positioning of text, people are
likely to be passing integers anyway. Or if they happen to be passing
0.5 values, (as in the case of these tests), then they don't _really_
care exactly where the text is being positioned.

On the other hand, this will be a fairly "large" change in the output
compared to anything we've done before.

Anyone want to make an argument one way or the other on this one?

-Carl

PS. Still working on those cairo-perf number from the n770. It appears
that cairo-perf is crashing on some of the "harder" tests, (I just saw
my n770 reboot some time after "tessellate" but it doesn't appear to
be entirely deterministic).
-------------- 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/b8fa8764/attachment.pgp