Re: Test harness and test suite assumptions wrt anti-aliasing (font smoothing, clearType)

GĂ©rard Talbot wrote:

> > Browsers typically render text with
> > subpixel antialiasing *and* with subpixel or integer-pixel
> > positioning. All browsers support subpixel anti-aliasing but only
> > Firefox/IE9 use subpixel positioning, Webkit/Opera use integer-pixel
> > positioning. Line metrics may be calculated with precise or rounded
> > metrics and where exactly the rounding occurs is not defined
> > precisely.  Under Windows, hinting will also affect these metrics for a
> > given font size, depending on the font.  All of these factors will
> > affect the
> > precise placement.  Only disabling subpixel anti-aliasing will still
> > leave you with other factors that affect placement.
> Of course it will leave the other factors that affect placement. Why
> should we want to have many factors affect precise placement of text
> when automated checking of tests start? Why not eliminate sources of
> differential rendering, especially if such sources are entirely outside
> the realm of CSS spec?

If you're seeing subpixel anti-aliasing affect a test, then it's a
sign that the text in question isn't placed precisely such that it
lands on integer pixel boundaries.  So that's either a bug in the
browser or a bug in the test.  For example, many tests I've seen are
in subtle ways dependent upon the metrics of the default font when
they really shouldn't be.

> I create reftests and there are quite a lot razor sharp tests in the
> test suite, you know.

That's fine as long as the tests are constructed such that placement
will always be precise, independent of default font choice or locale 
for example.

> 10 min. ago, I had anti-aliasing turn off (under Linux KDE 4.8.1) and
> both these webpages looked perfectly identical in Firefox 11.0.
> Then I re-enabled anti-aliasing, rebooted and reloaded these 2 webpages
> and, this time, there is a 1px height of difference for the black
> stripe. Clearly noticeable.

I don't have a Linux build handy right now, but I would say there's
either a bug in the test, such that there's a subpixel overlap, or
it's a bug in the browser.  Turning off subpixel anti-aliasing is just
masking whatever the underlying bug is, either in the test or in the

In this case, my guess is that this is a bug in Firefox/Linux, bug
604836, which you're aware of. [1]

> > The other reason for not doing this is that it's not an
> > environment users typically use and so you won't be testing the
> > main codepath that browsers use, you'll be using a modified
> > non-subpixel-AA path.
> It's certainly a valid reason... but machines, softwares doing
> automated checking of tests with reftests won't be understanding:
> it's identical or not.

I think whether the testing is automated or not is somewhat orthogonal,
the underlying codepath should be similar to the one being used to render
layouts in a given user's environment.

My point is simply that the tests should be testing only what they are
trying to test, for example "does the size of a box 16px x 16px match
the rendering of 16px Ahem".  If the baseline is not on a pixel
boundary then whether it lines up will depend on rounding rules that
aren't precisely defined in CSS and we shouldn't have tests that rely
on those rules.




Received on Saturday, 17 March 2012 07:25:21 UTC