Bug 222665 – Allow CSS font-styling for canvas without RenderStyle

• Component: Canvas
• Status: RESOLVED FIXED

[Chris Lord]

Currently, resolveForFontRaw requires RenderStyle, not for any good reason beyond the functions it needs to use expect it. It would be good to refactor and remove that dependency to make it easier for Workers in the future. (I suppose it's also a potential memory/perf improvement)

[Chris Lord]

Created attachment 422118 [details]
Patch

[Chris Lord]

Created attachment 422128 [details]
Patch

[Chris Lord]

Created attachment 422208 [details]
Patch

[Chris Lord]

Created attachment 422222 [details]
Patch

[Darin Adler]

Comment on attachment 422222 [details]
Patch

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

> Source/WebCore/css/CSSPrimitiveValue.h:194
> +    static double computeUnzoomedNonCalcLengthDouble(CSSUnitType, double value, CSSPropertyID, const FontMetrics* = nullptr, const FontCascadeDescription* = nullptr, const FontCascadeDescription* rootFontDescription = nullptr, const RenderView* = nullptr);

I worry about the long list of arguments. Is there any way for us to cut that complexity down to size? This is why we end up creating objects to group the context for calls like this.

Also wonder if there’s a more terse way to name these variations.

> Source/WebCore/css/CSSToLengthConversionData.h:78
> +    CSSPropertyID propertyToCompute() const { return m_propertyToCompute ? *m_propertyToCompute : CSSPropertyInvalid; }

Can use valueOr for this sort of thing.

> Source/WebCore/style/StyleFontSizeFunctions.h:28
> +#include "Settings.h"

Really annoying that Settings::Values creates these additional header dependencies. I think we should consider defining SettingsValues at the namespace level to avoid the need for all these additional header includes.

> Source/WebCore/style/StyleFontSizeFunctions.h:41
> +enum class MinimumFontSizeRule {
> +    None,
> +    Absolute,
> +    AbsoluteAndRelative
> +};

Comment on "just moved" code: I may be the only person who feels this way, but I like the one-line versions of this kind of small enum rather than the vertical version.

    enum class MinimumFontSizeRule : uint8_t { None, Absolute, AbsoluteAndRelative };

It’s also a tiny bit helpful, I think, to mark the underlying type uint8_t rather than letting it default to signed 32-bit integer.

> Source/WebCore/style/StyleResolveForFontRaw.cpp:202
> +    // Line height is non-existent on FontCascade, so is left unhandled.

Is there a slightly more precise way to say what we mean by "left unhandled"?

[Chris Lord]

Created attachment 422350 [details]
Patch

[Chris Lord]

(In reply to Darin Adler from comment #5)
> > Source/WebCore/css/CSSPrimitiveValue.h:194
> > +    static double computeUnzoomedNonCalcLengthDouble(CSSUnitType, double value, CSSPropertyID, const FontMetrics* = nullptr, const FontCascadeDescription* = nullptr, const FontCascadeDescription* rootFontDescription = nullptr, const RenderView* = nullptr);
> 
> I worry about the long list of arguments. Is there any way for us to cut
> that complexity down to size? This is why we end up creating objects to
> group the context for calls like this.
> 
> Also wonder if there’s a more terse way to name these variations.

I didn't address this - I think ideally, CSSToLengthConversionData would have another constructor that would take these arguments and accessors for them that could use them or defer to the style members... But that's a bigger change than I'd like to make at this stage and I think doing that nicely takes a bit more thought than a quick change on this patch.

> > Source/WebCore/css/CSSToLengthConversionData.h:78
> > +    CSSPropertyID propertyToCompute() const { return m_propertyToCompute ? *m_propertyToCompute : CSSPropertyInvalid; }
> 
> Can use valueOr for this sort of thing.

Thanks, fixed.

> > Source/WebCore/style/StyleFontSizeFunctions.h:28
> > +#include "Settings.h"
> 
> Really annoying that Settings::Values creates these additional header
> dependencies. I think we should consider defining SettingsValues at the
> namespace level to avoid the need for all these additional header includes.

I agree, I've opened bug 222788.

> > Source/WebCore/style/StyleFontSizeFunctions.h:41
> > +enum class MinimumFontSizeRule {
> > +    None,
> > +    Absolute,
> > +    AbsoluteAndRelative
> > +};
> 
> Comment on "just moved" code: I may be the only person who feels this way,
> but I like the one-line versions of this kind of small enum rather than the
> vertical version.
> 
>     enum class MinimumFontSizeRule : uint8_t { None, Absolute,
> AbsoluteAndRelative };
> 
> It’s also a tiny bit helpful, I think, to mark the underlying type uint8_t
> rather than letting it default to signed 32-bit integer.

Agreed on both counts and so I made the change. I'll wait for some green before cq+ in case there was some dubious casting going on that this breaks.

> > Source/WebCore/style/StyleResolveForFontRaw.cpp:202
> > +    // Line height is non-existent on FontCascade, so is left unhandled.
> 
> Is there a slightly more precise way to say what we mean by "left unhandled"?

I've updated this comment, "left unhandled" is indeed too vague. This now reads:

    // As there is no line-height on FontCascade, there's no need to resolve
    // it, even though there is line-height information on FontRaw.

[EWS]

Found 1 new test failure: platform/mac/media/encrypted-media/fps-encrypted-event.html

[Chris Lord]

Comment on attachment 422350 [details]
Patch

I don't think the failure has anything to do with this patch, trying again.

[EWS]

Committed r273964: <https://commits.webkit.org/r273964>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 422350 [details].

[Radar WebKit Bug Importer]

<rdar://problem/75093446>