Bug 10531 - cairo nquartz backend floating point precision issues
Summary: cairo nquartz backend floating point precision issues
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: quartz backend (show other bugs)
Version: 1.4.3
Hardware: Other All
: medium blocker
Assignee: Vladimir Vukicevic
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-05 02:25 UTC by Brian Ewins
Modified: 2007-04-05 16:08 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Brian Ewins 2007-04-05 02:25:58 UTC
Just tracking downstream bug/patch:
https://bugzilla.mozilla.org/show_bug.cgi?id=374006

"...if the string is long enough this [rounding] error actually
changes the subpixel rendering of the glyphs at the end of the string."

I've tested Roc's patch, it makes zero difference to any of cairo's test cases, but we don't have any long enough lines of text.

Its a straightforward fix, we should push this for 1.4.4.
Comment 1 Carl Worth 2007-04-05 10:10:28 UTC
(In reply to comment #0)
> I've tested Roc's patch, it makes zero difference to any of cairo's test cases,
> but we don't have any long enough lines of text.

Sounds like writing a test with a long-enough string is the right place to start then...

-Carl
Comment 2 Brian Ewins 2007-04-05 15:23:35 UTC
Good point Carl. And after 2048 pixels-width of Lorem Ipsum, I still couldn't reproduce the bug.

_cairo_atsui_font_text_to_glyphs uses the glyph positions from ATSUI pretty directly, but that isn't the case with Gecko - see eg
http://lxr.mozilla.org/seamonkey/source/gfx/thebes/src/gfxFont.cpp#191
> // Multiplying by the reciprocal may introduce tiny error here,
> // but we assume cairo is going to round coordinates at some stage
> // and this is faster
> glyph->x = ToDeviceUnits(x, devUnitsPerAppUnit);

So, to test this I made _cairo_atsui_font_text_to_glyphs increase all glyph advances by 0.0001 pixels. This reproduces the bug - one glyph over the 2048 pixels gets enough cumulative shift to have a visible effect, and the patch fixes it.

I could implement this as a test rather than a hack (by explicitly mis-positioning a few hundred glyphs, then calling show_glyphs). I'm not sure how worthwhile that is.
Comment 3 Carl Worth 2007-04-05 15:34:32 UTC
(In reply to comment #2)
> I could implement this as a test rather than a hack (by explicitly
> mis-positioning a few hundred glyphs, then calling show_glyphs). I'm not sure
> how worthwhile that is.

Well, no need to go to extreme measures. Why don't you just push the fix in---it looks small enough, and not something we're likely to reintroduce.

-Carl
Comment 4 Brian Ewins 2007-04-05 16:08:09 UTC
pushed as d801aa59f84d95568e36d02a0ecf3544b9914187


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.