Bug 102428 – Support geometricPrecision for HTML elements

• Status: NEW
• Component: Layout and Rendering

[Emil A Eklund]

Add geometricPrecision support for html elements. text-rendering: geometricPrecision is currently supported for SVG elements and text-rendering: optimizeSpeed | optimizeLegibility is supported for html elements. 

Downstream chromium bug: http://code.google.com/p/chromium/issues/detail?id=154882

[Emil A Eklund]

Created attachment 174511 [details]
Proof of concept patch, do not review.

[WebKit Review Bot]

Attachment 174511 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/fast/sub-pixel/geometric-preci..." exit_code: 1
Source/WebCore/platform/graphics/FontCache.cpp:66:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Source/WebCore/platform/graphics/FontCache.cpp:67:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Source/WebCore/platform/graphics/skia/FontCacheSkia.cpp:183:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Total errors found: 3 in 22 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Early Warning System Bot]

Comment on attachment 174511 [details]
Proof of concept patch, do not review.

Attachment 174511 [details] did not pass qt-wk2-ews (qt):
Output: http://queues.webkit.org/results/14857358

[kov's GTK+ EWS bot]

Comment on attachment 174511 [details]
Proof of concept patch, do not review.

Attachment 174511 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/14844646

[EFL EWS Bot]

Comment on attachment 174511 [details]
Proof of concept patch, do not review.

Attachment 174511 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/14833881

[Early Warning System Bot]

Comment on attachment 174511 [details]
Proof of concept patch, do not review.

Attachment 174511 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/14846582

[Build Bot]

Comment on attachment 174511 [details]
Proof of concept patch, do not review.

Attachment 174511 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/14845692

[Peter Beverloo (cr-android ews)]

Comment on attachment 174511 [details]
Proof of concept patch, do not review.

Attachment 174511 [details] did not pass cr-android-ews (chromium-android):
Output: http://queues.webkit.org/results/14847646

[Build Bot]

Comment on attachment 174511 [details]
Proof of concept patch, do not review.

Attachment 174511 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/14873094

Comment on attachment 174511 [details]
Proof of concept patch, do not review.

This platform-specific patch appears to tie geometricprecision to two behaviors:
1. Allowing text runs to have non-integer widths
2. Allowing non-integral pixel font sizes

(1) is already the behavior of OS X WebKit, for all values of the text-rendering property

What’s the motivation for making (1) opt-in on any port, rather than enabling it by default for the port that doesn’t have it yet?

What’s the motivation for making (2) opt-in, rather than enabling it by default for all ports?

[Emil A Eklund]

Thanks for taking a look at the patch, I appreciate your input.

(In reply to comment #10)
> (From update of attachment 174511 [details])
> This platform-specific patch appears to tie geometricprecision to two behaviors:
> 1. Allowing text runs to have non-integer widths
> 2. Allowing non-integral pixel font sizes

The reason I elected to have both behavior changes toggled by an option (and the same option at that) is to aid in testing as it allows side-by-side comparisons on a single page with a single build.
For the final change, if we decide to go ahead with it, this will most likely change.


> 1. Allowing text runs to have non-integer widths
> What’s the motivation for making (1) opt-in on any port, rather than enabling it by default for the port that doesn’t have it yet?

As you mention this is the default behavior for the apple mac port. I'll likely change chromium to enable this by default as well.

> 2. Allowing non-integral pixel font sizes
> What’s the motivation for making (2) opt-in, rather than enabling it by default for all ports?

The motivation behind making this opt-in is that the font rendering quality may suffer when scaled to a non-integral size. This is obviously platform dependent where some platforms handles non-integral sizes better than others. As long as there is a noticeable change in font rendering quality though it seems undesirable to enable the behavior by default.

[Emil A Eklund]

Getting subpixel font rendering to work correctly on windows will likely require us to use DirectWrite (as opposed to GDI) for font rendering. Still looking at other options but long-term it seems like moving the DirectWrite is the way to go.

Microsoft moved to DirectWrite with IE 9 and Mozilla with Firefox 6.

[Eric Seidel (no email)]

This seems like a totally reasonable feature to add to the platform.  Interested to hear from mitz that non-integer widths is already available by default on Mac.

It sounds like you need help from a Windows font-ninja to move forward Emil?  I remember brettw did much of the initial windows font stuff for Chromium, but perhaps there are Skia folks who would be willing to help you these days?

[Emil A Eklund]

(In reply to comment #13)
> This seems like a totally reasonable feature to add to the platform.  Interested to hear from mitz that non-integer widths is already available by default on Mac.
> 
> It sounds like you need help from a Windows font-ninja to move forward Emil?  I remember brettw did much of the initial windows font stuff for Chromium, but perhaps there are Skia folks who would be willing to help you these days?

I'm working with the skia team on this. Still not sure if we'll expose it though geometricPrecision or just do it by default though.

[Eric Seidel (no email)]

(In reply to comment #14)
> (In reply to comment #13)
> > This seems like a totally reasonable feature to add to the platform.  Interested to hear from mitz that non-integer widths is already available by default on Mac.
> > 
> > It sounds like you need help from a Windows font-ninja to move forward Emil?  I remember brettw did much of the initial windows font stuff for Chromium, but perhaps there are Skia folks who would be willing to help you these days?
> 
> I'm working with the skia team on this. Still not sure if we'll expose it though geometricPrecision or just do it by default though.

OK.  I might just start with geometric-precision and move from there if that's a success.