Bug 69135 – Rebaseline for bug 65583 (path based border radius drawing on skia) part 7

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Ben Wells]

Rebaseline for bug 65583 (path based border radius drawing on skia) part 7

[Ben Wells]

Created attachment 109262 [details]
Patch

[Ben Wells]

Comment on attachment 109262 [details]
Patch

Final rebaseline for bug 65583.

[James Robinson]

Comment on attachment 109262 [details]
Patch

I think LayoutTests/platform/chromium-win/fast/transforms/transformed-caret-expected.png and possibly others are baselining in a windows skia bug where the font's aliased to hell instead of smooth.  Can you double check the cr-win baselines?

[Ben Wells]

Yep, you're right. Rotated text is horrible, and even large text (e.g. header style) looks aliased. E.g. LayoutTests/platform/chromium-win/fast/css-generated-content/012-expected.png.

I'll remove these baselines and update the patch. I searched for a bug re skia font aliasing on Windows without luck - is one logged?

BTW a similar baseline came in for LayoutTests/platform/chromium-win/editing/selection/transformed-selection-rects-expected.png with bug 68608, I'll sort that out too.

[Ben Wells]

I found chrome bug 96769, I'm assuming that's it.

[Ben Wells]

Created attachment 109289 [details]
Patch

[Ben Wells]

Comment on attachment 109289 [details]
Patch

Removed the baselines and added expectations linked to crbug 96769. If this is wrong bug let me know and I will link to correct one / log a new bug.

I removed the baselines for windows image baselines using large fonts and rotated fonts. Looking again *all* windows text looks aliased compared to Linux. E.g. if you zoom right into LayoutTests/platform/chromium-win/fast/css/border-height-expected.png there is no anti-aliasing.

 Is that right / expected, or a known problem?

[Ben Wells]

After further investigation suggested by jamesr, the problems I'm seeing with fonts are all DumpRenderTree specific - they don't happen with Chrome 16.0.891.0 on Windows (which does seem to have crbug 69769). I've logged a new webkit bug 69213 for this, if it is not considered a problem worth fixing I can kill the bug.

For these rebaselines: the text does look horrible, in particular the rotated text, but I don't think they should be left as expected failures for webkit bug 69213. If that bug is ever fixed and DRT renders text with anti-aliasing there will be roughly a zillion tests to rebaseline.

I'll put the original patch back up for review.

[Ben Wells]

To be sure the text aliasing is DRT only I just rebuilt Chromium on Windows with ToT WebKit, and can confirm it doesn't show aliasing in rotated text with fast/transforms/transformed-caret.html.

[Ben Wells]

Any thoughts on this? I marked bug 69213 (for DRT text being different) as invalid as it is intentional.

Rotated text being aliased doesn't seem to be new and is already in at least this baseline:

http://trac.webkit.org/export/96652/trunk/LayoutTests/platform/chromium-win/fast/transforms/transform-on-inline-expected.png

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Ftransforms%2Ftransform-on-inline.html

[James Robinson]

Comment on attachment 109262 [details]
Patch

Sorry, this slipped my mind.  I think is fine.

[WebKit Review Bot]

Comment on attachment 109262 [details]
Patch

Clearing flags on attachment: 109262

Committed r96659: <http://trac.webkit.org/changeset/96659>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.