Implement text-underline-offset and text-decoration-thickness

• Component: New Bugs
• Status: RESOLVED FIXED

[Myles C. Maxfield]

Implement text-decoration-offset and text-decoration-width

[Myles C. Maxfield]

Created attachment 352858 [details]
Parsing support

[EWS Watchlist]

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


ERROR: Source/WebCore/ChangeLog:8:  You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible.  [changelog/nonewtests] [5]
Total errors found: 1 in 15 files


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

[Myles C. Maxfield]

Created attachment 352859 [details]
Needs to actually move/resize the decorations

[EWS Watchlist]

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


ERROR: Source/WebCore/ChangeLog:8:  You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible.  [changelog/nonewtests] [5]
Total errors found: 1 in 13 files


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

[Don Olmstead]

Comment on attachment 352859 [details]
Needs to actually move/resize the decorations

View in context: https://bugs.webkit.org/attachment.cgi?id=352859&action=review

Informal review

One question is whether there can just be a common base class here since they just mirror each other.

> Source/WebCore/rendering/style/TextDecorationOffset.h:99
> +    enum class Type {
> +        Auto,
> +        FromFont,
> +        Length
> +    };

Do you want to type this into a uint8_t?

> Source/WebCore/rendering/style/TextDecorationThickness.h:102
> +        : m_type(type)

We want to use {} for these now?

[Myles C. Maxfield]

(In reply to Don Olmstead from comment #5)
> Comment on attachment 352859 [details]
> Needs to actually move/resize the decorations
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=352859&action=review
> 
> Informal review
> 
> One question is whether there can just be a common base class here since
> they just mirror each other.

Yeah, my first version of the patch had them be the same class. However, due to https://github.com/w3c/csswg-drafts/issues/3118 I wanted to keep the implementation as flexible as possible in case the whole feature changes.

> 
> > Source/WebCore/rendering/style/TextDecorationOffset.h:99
> > +    enum class Type {
> > +        Auto,
> > +        FromFont,
> > +        Length
> > +    };
> 
> Do you want to type this into a uint8_t?

Yes, you're right!
> 
> > Source/WebCore/rendering/style/TextDecorationThickness.h:102
> > +        : m_type(type)
> 
> We want to use {} for these now?

Yes!

[Myles C. Maxfield]

Created attachment 353253 [details]
WIP

[Myles C. Maxfield]

Things remaining to do:

1. Make sure the repaint rects are correct (investigate RenderStyle::changeAffectsVisualOverflow(), visualOverflowForDecorations() and TextDecorationPainter::paintTextDecoration(), and computeUnderlineOffset())

2. Figure out what to do with maxLogicalBottomForTextDecorationLine()

3. Make sure flipped writing modes (like Mongolian) work

4. Make sure baselines (like CJK centered baseline) work correctly

5. Don's comments

[Myles C. Maxfield]

Created attachment 353335 [details]
WIP

[Myles C. Maxfield]

Created attachment 353579 [details]
WIP

[Myles C. Maxfield]

Things remaining to do:

1. Add some repaint rect code in addTextBoxVisualOverflow()
2. Split this patch up so it's easier to review
3. Write some tests
3a. Tests for animations
3b. Tests for text-shadow and underlines
3c. Tests for flipped writing-mode
3d. Tests for ideographic baseline
3e. Tests for the direction the decoration is offset in the various modes
4. (Optional) Make the underline go behind the text (See https://bugs.webkit.org/show_bug.cgi?id=190764)

[Myles C. Maxfield]

Created attachment 353951 [details]
Patch

[Don Olmstead]

Comment on attachment 353951 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=353951&action=review

LGTM. Just wondering about that constant.

> Source/WebCore/rendering/TextDecorationPainter.cpp:288
> +            int offset = computeUnderlineOffset(m_lineStyle.textUnderlinePosition(), m_lineStyle.textUnderlineOffset(), m_lineStyle.fontMetrics(), m_inlineTextBox, m_lineStyle.computedFontSize() / 16);

It worth moving from a magic number to a constant to give some meaning here?

> Source/WebCore/rendering/style/TextDecorationThickness.h:81
> +            const float textDecorationBaseFontSize = 16;

Here's that 16 again

[Dean Jackson]

Comment on attachment 353951 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=353951&action=review

> Source/WebCore/page/animation/CSSPropertyAnimation.cpp:1703
> +        new PropertyWrapper<TextDecorationThickness>(CSSPropertyTextDecorationThickness, &RenderStyle::textDecorationThickness, &RenderStyle::setTextDecorationThickness),
> +        new PropertyWrapper<TextUnderlineOffset>(CSSPropertyTextUnderlineOffset, &RenderStyle::textUnderlineOffset, &RenderStyle::setTextUnderlineOffset),

Animation! very nice.

>> Source/WebCore/rendering/TextDecorationPainter.cpp:288
>> +            int offset = computeUnderlineOffset(m_lineStyle.textUnderlinePosition(), m_lineStyle.textUnderlineOffset(), m_lineStyle.fontMetrics(), m_inlineTextBox, m_lineStyle.computedFontSize() / 16);
> 
> It worth moving from a magic number to a constant to give some meaning here?

Agreed.

[Myles C. Maxfield]

Committed r237903: <https://trac.webkit.org/changeset/237903>

[Radar WebKit Bug Importer]

<rdar://problem/45861917>

[Myles C. Maxfield]

*** Bug 167326 has been marked as a duplicate of this bug. ***

[Myles C. Maxfield]

*** Bug 167327 has been marked as a duplicate of this bug. ***

[Saam Barati]

Could this change have a performance impact? It's in the range where we have a 1-1.5% speedometer 2 regression on iOS.

https://trac.webkit.org/log/webkit/trunk?verbose=on&rev=237910&stop_rev=237896

[Saam Barati]

(In reply to Saam Barati from comment #19)
> Could this change have a performance impact? It's in the range where we have
> a 1-1.5% speedometer 2 regression on iOS.
> 
> https://trac.webkit.org/log/webkit/
> trunk?verbose=on&rev=237910&stop_rev=237896

This is an even narrower range:
https://trac.webkit.org/log/webkit/trunk?verbose=on&rev=237903&stop_rev=237899

This patch seems like the likely culprit.

[Myles C. Maxfield]

(In reply to Saam Barati from comment #20)
> (In reply to Saam Barati from comment #19)
> > Could this change have a performance impact? It's in the range where we have
> > a 1-1.5% speedometer 2 regression on iOS.
> > 
> > https://trac.webkit.org/log/webkit/
> > trunk?verbose=on&rev=237910&stop_rev=237896
> 
> This is an even narrower range:
> https://trac.webkit.org/log/webkit/
> trunk?verbose=on&rev=237903&stop_rev=237899
> 
> This patch seems like the likely culprit.

I could believe it. This patch deals with repaint rects of text; causing text to repaint more often could be a regression.

[Chris Dumez]

Confirmed as a PLT regression.