Bug 216931 - Reduce the reliance on PseudoElement in the animation code
Summary: Reduce the reliance on PseudoElement in the animation code
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Animations (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Antoine Quint
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-09-24 09:51 PDT by Antoine Quint
Modified: 2021-01-12 11:05 PST (History)
19 users (show)

See Also:


Attachments
Patch (115.43 KB, patch)
2020-09-24 09:59 PDT, Antoine Quint
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (115.90 KB, patch)
2020-09-24 10:25 PDT, Antoine Quint
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (116.58 KB, patch)
2020-09-24 11:19 PDT, Antoine Quint
no flags Details | Formatted Diff | Diff
Patch (120.16 KB, patch)
2020-09-25 06:02 PDT, Antoine Quint
no flags Details | Formatted Diff | Diff
Patch (119.98 KB, patch)
2020-09-25 06:42 PDT, Antoine Quint
ews-feeder: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Antoine Quint 2020-09-24 09:51:40 PDT
Reduce the reliance on PseudoElement in the animation code
Comment 1 Antoine Quint 2020-09-24 09:59:43 PDT
Created attachment 409588 [details]
Patch
Comment 2 Antoine Quint 2020-09-24 10:14:17 PDT
I have a few open questions about this patch:

1. Should we use Optional<const Styleable> or even Optional<Styleable> instead of const Optional<const Styleable>?

2. Should the element member of Styleable be Ref<Element> instead of Element&?

3. Should we expose methods to access ElementAnimationRareData on Styleable directly? This would allow writing styleable.ensureAnimations() instead of styleable.element.ensureAnimations(styleable.pseudoId).

And some notes about places where I couldn't yet find a way out of using PseudoElement:

1. In KeyframeEffect::didChangeTargetStyleable(), in order for Element::invalidateStyleInternal() to be called on the new target, we have to ensure we create a PseudoElement in case the target is a pseudo-element.

2. In Style::TreeResolver::createAnimatedElementUpdate() we also require the use of PseudoElement to call Element::renderOrDisplayContentsStyle() on it. We would need a way to obtain the same RenderStyle object based on an Element/PseudoId combination.

3. In Style::TreeResolver::resolvePseudoStyle() we also require the use of PseudoElement.

4. KeyframeEffect::renderer() is another place where we rely on PseudoElement still in order to get the target RenderElement for the Element/PseudoId pair.
Comment 3 Antoine Quint 2020-09-24 10:25:47 PDT
Created attachment 409592 [details]
Patch
Comment 4 Radar WebKit Bug Importer 2020-09-24 10:28:28 PDT
<rdar://problem/69511682>
Comment 5 Antoine Quint 2020-09-24 11:19:23 PDT
Created attachment 409605 [details]
Patch
Comment 6 Antti Koivisto 2020-09-25 02:07:27 PDT
Comment on attachment 409605 [details]
Patch

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

> Source/WebCore/animation/WebAnimationUtilities.cpp:65
> +        if (pseudoId == PseudoId::None)
> +            return NotPseudo;
> +        if (pseudoId == PseudoId::Marker)
> +            return Marker;
> +        if (pseudoId == PseudoId::Before)
> +            return Before;
> +        if (pseudoId == PseudoId::After)
> +            return After;

switch?

> Source/WebCore/animation/WebAnimationUtilities.cpp:73
> +    auto pseudoIdAsString = [](PseudoId pseudoId) -> String {
> +        TextStream stream;
> +        stream << pseudoId;
> +        return stream.release();
> +    };

I think TextStreams are mostly just for debugging. If there isn't a general function for this you should write it.

However since PseudoId set is fixed you could also just provide sorting order for all of them and avoid the strings for now.

> Source/WebCore/dom/ElementRareData.h:178
> -    std::unique_ptr<ElementAnimationRareData> m_animationRareData;
> +    HashMap<PseudoId, std::unique_ptr<ElementAnimationRareData>, WTF::IntHash<PseudoId>, WTF::StrongEnumHashTraits<PseudoId>> m_animationRareData;

I think this would almost always have zero-to-one and at most a couple of members. HashMap seem bit heavyweight for that. Maybe just use a Vector?

> Source/WebCore/rendering/RenderElement.cpp:2313
> +Optional<Styleable> RenderElement::styleable() const
> +{
> +    if (auto* element = this->element())
> +        return Styleable(*element, element->pseudoId());
> +    return WTF::nullopt;
> +}

Maybe put this to Styleable instead as something like

static Styleable fromRenderer(const RenderElement&)

RenderElement has enough stuff already.

This doesn't seem correct for before/after. 'element' will point to the PseudoElement instead of the host Element which doesn't match how the other code expects Styleable to work.

> Source/WebCore/style/Styleable.h:34
> +struct Styleable {

We might consider putting this to Style namespace but it is ok for now as-is.

> Source/WebCore/style/Styleable.h:42
> +    Styleable(Element& element, PseudoId pseudoId)
> +        : element(element)
> +        , pseudoId(pseudoId)
> +    {
> +    }

Asserting that element is not a PseudoElement would be good. Maybe it can also assert that if pseudo is before/after the PseudoElement exists on the element?

> LayoutTests/imported/w3c/web-platform-tests/css/css-transitions/non-rendered-element-002-expected.txt:2
> -Harness Error (TIMEOUT), message = null
> -
> -TIMEOUT Transitions on ::before/::after pseudo-elements are canceled when the content property is cleared Test timed out
> +PASS Transitions on ::before/::after pseudo-elements are canceled when the content property is cleared 

Would be good to understand this progression.
Comment 7 Antti Koivisto 2020-09-25 05:01:20 PDT
(In reply to Antoine Quint from comment #2)
> I have a few open questions about this patch:
> 
> 1. Should we use Optional<const Styleable> or even Optional<Styleable>
> instead of const Optional<const Styleable>?

Current use seems fine. 

> 2. Should the element member of Styleable be Ref<Element> instead of
> Element&?

Might be a good idea. We'll need to be careful with reference cycles if Stylable is used in containers.
 
> 3. Should we expose methods to access ElementAnimationRareData on Styleable
> directly? This would allow writing styleable.ensureAnimations() instead of
> styleable.element.ensureAnimations(styleable.pseudoId).

Probably better to keep Stylable simple.
Comment 8 Antoine Quint 2020-09-25 06:02:18 PDT
Created attachment 409683 [details]
Patch
Comment 9 Antoine Quint 2020-09-25 06:42:39 PDT
Created attachment 409687 [details]
Patch
Comment 10 Antoine Quint 2020-09-25 08:22:10 PDT
Committed r267571: <https://trac.webkit.org/changeset/267571>
Comment 11 EWS 2020-09-25 08:22:14 PDT
Tools/Scripts/svn-apply failed to apply attachment 409687 [details] to trunk.
Please resolve the conflicts and upload a new patch.
Comment 12 Antoine Quint 2021-01-12 11:05:34 PST
This caused bug 220550.