Bug 41363 - text-rendering:auto should enable optimizeLegibility >= 20px
: text-rendering:auto should enable optimizeLegibility >= 20px
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering
: 528+ (Nightly build)
: All All
: P3 Minor
Assigned To: Nobody
Depends on:
  Show dependency treegraph
Reported: 2010-06-29 11:25 PDT by Paul Irish
Modified: 2015-05-19 18:20 PDT (History)
10 users (show)

See Also:

Patch (170.85 KB, patch)
2011-01-20 02:34 PST, Yuzo Fujishima
mjs: review-
Details | Formatted Diff | Diff
Baseline performance (19.15 KB, text/html)
2011-01-20 22:19 PST, Yuzo Fujishima
no flags Details
Patch 79567 performance (19.21 KB, text/html)
2011-01-20 22:19 PST, Yuzo Fujishima
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Irish 2010-06-29 11:25:43 PDT
the community is very excited about text-rendering: http://www.aestheticallyloyal.com/public/optimize-legibility/

However it's very plausible people will do  ` body  { text-rendering: optimizeLegibility; } `
Due to what dave hyatt indicated here http://webk.it/6136#c3 I would suspect that is not a wise choice from a performance perspective.

The way that Firefox implements this feature is to enable optimizeLegibility for all text at and above 20px; 
I think that strikes a nice balance of making the text look beautiful when its large, but doesn't go overboard and sacrifice performance.

The MDC has a demo page: https://developer.mozilla.org/en/CSS/text-rendering
Comment 1 Yuzo Fujishima 2011-01-20 02:34:20 PST
Created attachment 79567 [details]
Comment 2 Yuzo Fujishima 2011-01-20 02:38:06 PST
I'll rebaseline 400 of layout tests if the reviewer(s) like the patch.
Comment 3 Simon Fraser (smfr) 2011-01-20 10:13:25 PST
I approve as long as it doesn't slow down normal page loading.
Comment 4 Yuzo Fujishima 2011-01-20 22:19:10 PST
Created attachment 79695 [details]
Baseline performance
Comment 5 Yuzo Fujishima 2011-01-20 22:19:52 PST
Created attachment 79697 [details]
Patch 79567 performance
Comment 6 Yuzo Fujishima 2011-01-20 22:30:56 PST
Thank you for the review.

I measured the performance difference using http://dev.chromium.org/developers/testing/page-cyclers.
Please see the attachements.
(If there are better performance tests to try, please give me the pointers to them.)

The performance goes down by 0.3%, but considering the standard deviation, the difference is insignificant.

(In reply to comment #3)
> I approve as long as it doesn't slow down normal page loading.

I'll rebaseline or modify the failing tests.
Comment 7 Dave Hyatt 2011-01-21 13:32:14 PST
I have a couple of concerns about this.

(1) It will cause animations and transitions on font-size to look really bad as you cross the 20px threshold, since kerning and ligatures will pop on and off.

(2) You are missing out on graphics context scaling from both SVG and from CSS transforms.  This means that the font may actually be rendered at larger or smaller sizes and that the size you see in the FontDescription isn't necessarily the size that the font is going to render at.  Ignoring CSS transforms does mean transform animations won't pop at least though.

Have you tested these cases in Firefox builds to see what they do?
Comment 8 Brett Wilson (Google) 2011-01-21 14:04:19 PST
There are already a lot of weird text popping effects as stuff is changed. On Windows, for example, we use Skia for rendering rotated text since Windows' looks bad, which causes an change as something rotates through horizontal. I haven't found these things to be that bad, and I haven't heard a lot of complaints about it.

We've had to fix a number of related bugs in this type of situation. For example, we had a bug where we were doing some custom image resampling to pre-transformed size, and the result was that the image looked really blurry. So this is a concern.

However, I wonder, in this case, would the CSS transforms not applying alleviate your concern about popping? It seems most people doing animations will use transforms, meaning that if you do, the styling won't change from the original size you specify.
Comment 9 Maciej Stachowiak 2011-04-26 16:26:16 PDT
Comment on attachment 79567 [details]

The comments from Dave and Brett seem to merit an r-.
Comment 10 Allan Sandfeld Jensen 2013-10-01 01:45:40 PDT
I should note that optimize-legibility should also enable kerning if it is default off. I am not sure you really want that. Normally you would rather disable kerning on bigger fonts, so geometricPrecision would make more sense.