OK, this bug is necessary for example like this: https://codepen.io/BorisChiou/pen/xpLbov

Bug 1586096 may have an impact on this because we set the anchor point to transform-origin if offset-anchor is auto. In other words, transform-origin animation may affect motion-path if offset-anchor is auto.

Hi Matt,

I have a question about getting the DrawTarget on the compositor thread for web-renderer. Actually, what I want is to build a gfx::Path in AnimationHelper::SampleAnimations(). Here is my original code for building the gfx::Path on main thread, and the compositor thread on non-wr:

  RefPtr<gfx::DrawTarget> drawTarget;
      gfxPlatform::GetPlatform()->ScreenReferenceDrawTarget();
  RefPtr<gfx::PathBuilder> builder =
      drawTarget->CreatePathBuilder(gfx::FillRule::FILL_WINDING);
  return SVGPathData::BuildPath(..., builder, ...);

However, it seems we cannot use gfxPlatform()::GetPlatform() for web-renderer on the compsitor thread (which is in GPU process?). I hit the assertion in gfxPlatform::Init() [1]. So how do I get the draw target on the compositor thread for web-renderer? I may use it in AnimationHelper::SampleAnimations() [2]. Thank you.

[1] Assertion failure: !XRE_IsGPUProcess() (GFX: Not allowed in GPU process.), at https://searchfox.org/mozilla-central/rev/171109434c6f2fe086af3b2322839b346a112a99/gfx/thebes/gfxPlatform.cpp#857
[2] https://searchfox.org/mozilla-central/rev/171109434c6f2fe086af3b2322839b346a112a99/gfx/layers/AnimationHelper.cpp#552

Or nical may know this:

Hi Nicolas, I'm trying to build a gfx::Path in web-renderer (e.g. WebRenderBridgeParent::AdvanceAnimations()). The caller is in GPU process I guess, so I cannot use gfxPlatform::GetPlatform()->ScreenReferenceDrawTarget() to get the DrawTarget on the compositor thread, right? (Because gfxPlatform cannot be initialized in GPU process) Do you have any suggestion to get DrawTarget in WebRenderBridgeParent::AdvanceAnimations()? Or Any way to get the PathBuilder if there is not DrawTarget in wr. Thanks.

I can see DrawTarget* is an argument of WebRenderBridgeParent::CompositeToTarget, we can probably use it. (the function ends up calling SampleAnimations). But I am not sure when SampleAnimations is called via nsIDOMWindowUtils.getOMTAStyle.

Yes, but unfortunately, it is always nullptr in web-renderer (i.e. we check MOZ_ASSERT(aTarget == nullptr); in this function).

I suspect I have to write a lightweight version of path builder which converts Span<const StylePathCommand> into FlattenedPath, so I don't have to care about DrawTarget because what we need is to call ComputePointAtLength and ComputeLenght in css pixel unit. This can be used by main thread and compositor thread (in layer and wr system).

Can you just create a DrawTargetSkia and use that to get a PathBuilder?

We have separate implementations of path builders, so that the backend can efficiently use the path you create, and so that any calculations done on the path match what will be rendered.

It sounds like you don't render the path itself (since you'd need a DrawTarget!), so neither of those matter. Skia's builder should be fine.

(In reply to Matt Woodrow (:mattwoodrow) from comment #10)

Can you just create a DrawTargetSkia and use that to get a PathBuilder?

We have separate implementations of path builders, so that the backend can efficiently use the path you create, and so that any calculations done on the path match what will be rendered.

It sounds like you don't render the path itself (since you'd need a DrawTarget!), so neither of those matter. Skia's builder should be fine.

Cool. yes we don't have to render the path. I will try to create DrawTargetSkia for this, just for calculation the angle and position. Thanks a lot.

I'd like to add some new data type for motion path, so it'd be great to
put all of them in an independent file.

The current implementation uses nsIFrame to get everything. However, we
want to reuse ResolveMotionPath() on the compositor thread (in the parent
process), so we need to refactor this function to avoid using nsIframe
everywhere.

On the compositor thread in GPU process (i.e. web-renderer), gfxPlatform() is
not initialized, so we don't have the DrawTarget information.
Fortunately, all we need is to calculate the motion point and direction
vector, so we don't have to care about which backend we use.

Therefore, make PathBuilder as a parameter, so we can just pass a valid
PathBuilder on the compositor thread. For main thread (i.e. content
process), using the original way is fine.

This also includes the implementation of SetAnimatable, FromAnimatable,
and merge the final matrix with motion path.

Besides, we always use PathBuilderSkia for calculating the gfx::Path for
web-renderer.

We cache the path in AnimationInfo for layers, and in
CompsoitorAnimationStorage for web-renderer.

We need to pass these two types into the compositor, so we need a better
way to serialize these rust types. We use serde and serde_json to
serialize/deserialize them. It's ok to use other Serializer, but it
seems we includes serde_json already, and it serizlize the type into a
string, so we can easily reuse it.

Comment on attachment 9103144 [details]
Bug 1429305 - No need to send non-animating offset-* if no effective motion path.

Revision D50012 was moved to bug 1592787. Setting attachment 9103144 [details] to obsolete.

https://hg.mozilla.org/mozilla-central/rev/fc105e53c1cd
https://hg.mozilla.org/mozilla-central/rev/6b0c544e7744
https://hg.mozilla.org/mozilla-central/rev/a3d6aab91bd4
https://hg.mozilla.org/mozilla-central/rev/7e71a2643d86
https://hg.mozilla.org/mozilla-central/rev/0a68f6ee4e49
https://hg.mozilla.org/mozilla-central/rev/5159301a8446
https://hg.mozilla.org/mozilla-central/rev/b0d2fc650478
https://hg.mozilla.org/mozilla-central/rev/012c857ee208