Rebaseline for bug 65583 (path based border radius drawing on skia) part 7
Created attachment 109262 [details] Patch
Comment on attachment 109262 [details] Patch Final rebaseline for bug 65583.
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?
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.
I found chrome bug 96769, I'm assuming that's it.
Created attachment 109289 [details] Patch
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?
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.
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.
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
Comment on attachment 109262 [details] Patch Sorry, this slipped my mind. I think is fine.
Comment on attachment 109262 [details] Patch Clearing flags on attachment: 109262 Committed r96659: <http://trac.webkit.org/changeset/96659>
All reviewed patches have been landed. Closing bug.