[css-animation] Motion Blur

[argyleink]

Why

Professional polish of motion graphics often includes the application of motion blur. In most cases, it's a boolean toggled at the layer level, that then tells the engine to set a blur amount based on the speed of the pixels. This effect makes animations much closer to real life, among other nice benefits. CSS currently is incapable of such an effect. Instead, a strobing, ghosted type effect is often what we get instead.

Motion blur, as is found in motion graphic tooling like After Effects, is not possible with current filters because each pixel is evaluated, not the entire layer. Each pixel is evaluated for velocity and blurred contextually. CSS blur() can only apply to the entire layer.

Use Cases / Contexts/ Value Props

• Brand fidelity
  • Broadcast industry
  • Animation industry
  • Release dependency on movie files for fidelity
• Tooling
  • Animation tooling (framer, marvel, etc)
  • Web video editing (caption animations, etc)
• Strobing pacification/correction
  • Lower framerate scenarios can be less janky
  • Closer to the physical world
  • Soften an animation
• Classic animation technique enablement
  • Taught in schools as a healthy technique
  • Enable animators and mographers to port more of their work to the web
• Fluid interfaces
  • All the above can help lead to more fluid interfaces
  • Will be very interesting to see motion blur paired with 2d transforms and touch interactions, especially if they have physics

Example (cylindrical motion)

No motion blur (pardon 15fps gif quality..)

With motion blur

note: edges have more blur than the center because they have more speed/movement per frame

Strobing effect found on the web today: Codepen

Proposal

.animated-layer {
  /* gpu accelerated animation */
  animation: rotate .5s linear infinite;

  /* request motion blur from the engine */
  motion-rendering: blur; /* inherit | initial | auto | none | blur */

  /* nice-to-have shutter angle, controls blur amount/intensity */
  motion-shutter-angle: 180deg; /* inherit | initial | auto = 180deg | [0deg, ..., 720deg] */
}

@keyframes rotate {
  to {
    transform: rotate(1turn);
  }
}

• default value is none
• in some cases it will create no effect (not enough speed, etc)

[AmeliaBR]

This is definitely something I've seen asked for. I've also seen it faked (for linear motion) with SVG filters (and there is a proposal to add unidirectional blur to the CSS shorthand). But it would be much better all around if the browser can calculate the amount of blur needed based on its frame rate and the motion being applied. Even better if the blur can be implemented at the GPU/compositing level.

Diving into the details:

• Would this approach work for other types of animations (like shape morphing or color transitions) or only transformations?

• Would the proposed shader implementation work for 3D translations, or only for flattened effects? If so, should motion-blur: blur be a flattening layer effect?

• Is it necessary to limit it to GPU-accelerated animations? We don't have any other properties (that I know of) that reference the rendering pathway. But we do have "hint" properties (shape-rendering, text-rendering, etc.) that indicate an author preference for certain optimizations if they are available. (Maybe this could be called motion-rendering?)

• Could we make the default auto to allow browsers to opt in to blurring by default if they discover it isn't much of a performance hit? I'm pretty sure this is an effect that you'd want most of the time, if it was available. (Of course, there should still be a none option to turn it off if the author has a reason to.)

[Martin-Pitt]

Hmm, I think it makes more sense as part of filter — as that has been acknowledged as being shader-related or post-processing. Esp. as filter is a function-stack.

E.g. filter: motion-blur(4px) Likewise backdrop-filter: motion-blur(4px)

The motion blur effect reminds me Unity's Shutter Speed Simulation from the GPU gems article.

I think if we can decide on a simple implementation like adding to the filter property, I'd be OK with this.

But motion blur might not be appropriate really for digital graphics, unless we are simulating a 3D scene and attempting photorealism.

Motion design artists don't actually like using motion blur, it's a common mistake by beginners. There's more to meaning in motion than blurs, read this article to understand: https://www.schoolofmotion.com/blog/motion-blur-after-effects

And even for 3D scenes, there are ways of doing non-blur motion: https://twitter.com/chriswade__/status/748050910417387520

I'm a bit wary of global 'motion-rendering' thing. Could I adjust the motion rendering between none, blur, smear, stretch & squash, etc per element? How can I adjust how much that effect happens? Sometimes you want to have super exaggerated effects, e.g. for slow motion or a cartoon style.

I am in awe the day when we will be able to do all these kinds of expressions of motion on the web: https://twitter.com/tonikopantoja/status/1075951567826644992

[argyleink]

@AmeliaBR Lovely reply and set of questions.

1. Would this approach work for other types of animations (like shape morphing or color transitions) or only transformations? I've personally only seen it used on scale/rotate/translate, unsure if it could/should apply to morphing or color. I'm leaning towards no, but I'm open minded.

1. Would the proposed shader implementation work for 3D translations, or only for flattened effects? If so, should motion-blur: blur be a flattening layer effect? I believe it should work for 3D translations. Elements in a perspective could be translated in space, and if they had motion-blur applied, as they are manipulated in that space with 3D properties, if the speed is fast enough, a blur should apply. I'm unsure if it should have a flattening layer effect, or if it should piggy back on other's applying that effect.

1. Is it necessary to limit it to GPU-accelerated animations? We don't have any other properties (that I know of) that reference the rendering pathway. But we do have "hint" properties (shape-rendering, text-rendering, etc.) that indicate an author preference for certain optimizations if they are available. (Maybe this could be called motion-rendering?) Necessary, maybe not, but I like that it encourages folks to not animate margin/padding/left/top/etc. It's also likely to be expensive computationally, and by piggybacking on promoted layers we can pacify and ease some of that work. I like the name motion-rendering. Keeps it open for future values. 👍

1. Could we make the default auto to allow browsers to opt in to blurring by default if they discover it isn't much of a performance hit? I'm pretty sure this is an effect that you'd want most of the time, if it was available. (Of course, there should still be a none option to turn it off if the author has a reason to.) I'm open to that idea 👍

@Martin-Pitt I'm open to your naming suggestion and placement in the filter rule. filter: motion-blur(4px)& backdrop-filter: motion-blur(4px). I had imagined a v2 of motion blur would allow folks to control shutter speed, but if it makes more sense to implement it in v1, I think folks would appreciate the control.

But motion blur might not be appropriate really for digital graphics, unless we are simulating a 3D scene and attempting photorealism.

Disagree here, motion blur has valuable use outside of those contexts.

Motion design artists don't actually like using motion blur, it's a common mistake by beginners. There's more to meaning in motion than blurs, read this article to understand:

Disagree here, I know many artists that like motion blur, and it's not our decision to say if it's for beginners or not. That mentality would prevent lots of great things from reaching CSS. Agree there's more to motion than blurs, Disney taught us a lot about motion and perception. Motion blur is definitely a basic/essential, but that doesn't make it only a beginner tool.

I'm a bit wary of global 'motion-rendering' thing

Can you unpack that a bit? I don't think a global motion blur or motion-rendering declaration is great either. Though sure, someone may apply it in their CSS. The proper usage would be putting it on an element you're moving quickly, and I like the requirement of it only applying to elements already promoted to layers in the GPU due to other best practice web animation strategies. Means applying it globally would have no effect.

Could I adjust the motion rendering between none, blur, smear, stretch & squash, etc per element?

@AmeliaBR's suggestion of naming to motion-rendering keeps your desires open ended, which I think would be super neat to see more values added over time.

How can I adjust how much that effect happens?

I like your idea of putting it into the filter area and taking a parameter. That would give the author the ability to control how much, similar to shutter speed, maybe even exactly like shutter speed. I also like Amelia's suggestion. Consider motion-rendering: blur(5px) squash(2px) vs filter: motion-blur(5px) motion-squash(2px)

I am in awe the day when we will be able to do all these kinds of expressions of motion on the web:

same hehe 😄 I'd love to see us be able to implement all 12 Disney principles of animation with ease, that would be amazing.

Hope I covered everyone's comments! Love them, keep em coming.

I want to throw one more scenario out there, food for thought, which is if motion-blur was applied to an element being dragged around. It would be fun and neat, but also a great cover up. We're often super obsessed with 60 (or even 120!) fps these days because of the delays of the items attached to our finger. Motion blur would likely pacify many of those uncanny visuals since the blur can help any dropped frames or uncanny stickiness. I think there's more fun to be had with this css property than outlined in the tiny statement above, as well as more utility than is outlined.

[AmeliaBR]

I think it makes more sense as part of filter (@Martin-Pitt )

That's very similar to the proposal from w3c/fxtf-drafts#50. I definitely still support having the ability to specify more complex blurs in the filter property.

But what is distinct about @argyleink's proposal here is that the blur would be calculated automatically based on the device's frame rate and the actual differences from one frame to the next. The author wouldn't need to figure out how to animate the amount of blur and its direction to match up with the speed of the motion.

That kind of automatic calculation doesn't really make sense in filter. All the other filter functions (even SVG filters) are simple pixel manipulations that can just as easily be applied to a static image representing the flattened rendering of the current element.

I'm a bit wary of global 'motion-rendering' thing.

I agree with Adam, that we should probably not think of this as a "global" setting, but as an effect targeted to a specific element that represents a moving layer. In other words, the property wouldn't inherit, and it would only have an effect if the same element is moving around.

…which basically answers one of my own questions: this should be solely about transform-like properties (aka, transform, the individual transform properties, SVG viewBox, and the motion path properties) and not about properties that change the paint rendering of the layer.

[jonjohnjohnson]

All the other filter functions (even SVG filters) are simple pixel manipulations that can just as easily be applied to a static image representing the flattened rendering of the current element.

@AmeliaBR What about backdrop-filter in conjunction with scrolling? See sticky positioned navs on apple.com which use backdrop blurring and show content scroll underneath. Could motion blur in some sense be tied to the frame rate alongside the speed and direction of scrolling in backdrop-filter?

[tabatkins]

Yeah, this is about movement specifically; while there are probably variants of motion blur that can do stuff with color, the traditional and widely-understood definition involves tracking how a given pixel moves between frames (calculated from the movement of the object and/or the movement of the "camera", so a pretty easy and quick bit of vector math), and then applying a blur along the direction of motion, proportional to the between-frame velocity.

The only thing in CSS that gives us that sort of tracking ability is tying it to the animation of 'transform' (and its family of properties) specifically. Luckily, that's also the common way to move things around, particularly in situations where you'd want motion blur!

[AmeliaBR]

What about backdrop-filter in conjunction with scrolling?

What's special about backdrop-filter is how you clip the layer image before applying the filter. But even when scrolling, you're only changing which parts of the layet get filtered, not which filter parameters get used (e.g., how much blur).

[jonjohnjohnson]

@AmeliaBR Though I'm skeptical about css motion blur in general, I'm not sure what your response means in regards to my question "Could motion blur in some sense be tied to the frame rate alongside the speed and direction of scrolling in backdrop-filter (or elsewhere)"?

[AmeliaBR]

Could motion blur in some sense be tied to the frame rate alongside the speed and direction of scrolling in backdrop-filter (or elsewhere)

Sorry, didn't read your comment closely enough! And I'm still not sure what you're asking about backdrop-filter.

But, I do think that it's worth considering "translations caused by scroll" as one of the transformation-like motions that could trigger motion blur in the compositor, if the scroll-container has the motion blur property turned on.

[argyleink]

agreed, scroll blur could be pretty neat. they're translated and in motion.

@jonjohnjohnson i'm also unsure of what you're asking for regarding backdrop-filter motion blur. if i'm tracking correctly, you're curious if the speed of the elements moving beneath a backdrop-filter could affect the amount of blur coming from the backdrop filter? like, you want to leverage the amount of blur coming from the speed of movement and apply it elsewhere? that makes the most sense to me, but it's not motion blur related imo. the whole point here being pixel by pixel getting a blur, not a layer getting a blur. in the rotation example above, the elements at the end get more blur than those in the middle. how would you want to use that blur mesh in backdrop filter? it's not a single value you can just apply. am i understanding correctly the ask?

[jonjohnjohnson]

you want to leverage the amount of blur coming from the speed of movement and apply it elsewhere?

@argyleink Yep, that's exactly question was about and @AmeliaBR answered it when she spoke of "translations caused by scroll". Pixel by pixel still applies even if not rotating. Your example could just be translating in a single direction and instead of a staggering discrete paints of the same block, you'd maybe want a motion blur based upon speed, no? This is all I was asking about. Scroll related motion blur that takes into account speed, direction, and frame rate, not simply "a layer getting a blur". And since I've seen some nice effects with backdrop blurring, like I mention from the use of navigation on apple.com, I'm simply wondering peoples thoughts in being able to use that alongside motion blurring for content moving via scrolling mechanics, not just transform.

[grorg]

There are many different variations of motion blur. Would the specification require everyone implement the same algorithm in all cases?

Motion blur is often added for offline rendering. For real time cases, would it be acceptable to drop the frame rate in order to add motion blur? How would you specify this in CSS?

[AmeliaBR]

@grorg We give implementations flexibility in picking the algorithm for simple blur, so I don't think we'd want to be any more specific for motion blur.

If we approach the property as a rendering hint, rather than an explicit style rule, then implementations would be able to use their own heuristics to decide the trade-off between frame rate and blur.

But maybe there could be two keywords, one for "motion blur, please, if it doesn't slow you down" (i.e., the usual request, to smooth out an animation) and one for maximum blur effect (i.e., if the blur itself is part of the design).

[tabatkins]

I'm assuming we'd just have a "none" (the default) and a "please, if you can" value, with the latter being defined by a general description but leaving the precise details up to the browser (including "no blur" as a valid implementation of the value).

[argyleink]

to recap some of the conversation and attempt alignment, here's the syntax I feel we're converging on:

.animated-layer {
  animation: rotate-forever .5s linear infinite;
  motion-rendering: blur; /* inherit | initial | auto | none | blur */

  /* throwing shutter angle in, would love to have it, but feels like a complexity multiplier */
  motion-shutter-angle: 180deg; /* inherit | initial | auto = 180deg | 0deg - 720deg */
}

@keyframes rotate-forever {
  to {
    transform: rotate(1turn);
  }
}

what tweaks would you like to see to the above?

[AmeliaBR]

That looks good to me. Other key points from the discussion, as I understand it:

• The property should have no side effects; it doesn't force a compositor layer on its own & doesn't change rendering for non-moving elements.
• User agents would have some flexibility in deciding which types of movement do trigger motion blur (for auto but also for blur). It could include scrolling motions as well as transforms and motion path. It wouldn't normally include changes that are implemented with repaints on each frame.
• The exact blurring algorithms would be implementation dependent. When deciding which motions trigger blur, user agents should make reasonable trade-offs to create an overall smooth animation.
• Adding this property doesn't prevent CSS adding directional blurring to filter (etc.) for more direct author control of smear/swipe effects, in the future.

Next step would be to get feedback from implementers on how easy/hard this would be to implement & whether they're likely to do so if it gets spec'd.

[jonjohnjohnson]

@AmeliaBR & @argyleink I know my questions about scrolling might not be about the most common cases, but here's a quick demo/gif to aid in understanding my crazy talk.

From left to right, imaging the scrolling with smearing/blur based upon direction/speed.

• backdrop-filter: scroll-blur() with content scrolling behind
• backdrop-filter scroll-blur() scrolling over static content
• filter: scroll-blur() on content scrolling

https://jsfiddle.net/jonjohnjohnson/27w95rc6/

[flackr]

The linked gpu gem uses a trick for calculating motion blur where the previous camera position is used, however the proposal here is about the element's motion which isn't global across the scene. This likely adds complexity to the implementation as we'd have to know for each pixel the motion of the object at that pixel within the scene.

Scrolling motion blur might be simpler, though we still have to know which parts of the scene are elements which do not move with scrolling (i.e. position: fixed / position: sticky).

[argyleink]

some interesting points about motion blur and it's usefulness from Apple (starts at ~19m) https://developer.apple.com/videos/play/wwdc2018/803/

• encode more information into the motion for your eyes
• pacifies visual strobing

[flackr]

If we target a specific element/layer, I think we could expose a previous transform (e.g. 1/60th of a second ago) which would enable a shader to compute the previous location of that pixel and blur along that direction vector. Of course for spinning things this wouldn't quite be right (blurring across a line rather than an arc) but the error in most cases might not be too noticeable.

• The property should have no side effects; it doesn't force a compositor layer on its own & doesn't change rendering for non-moving elements.

I suspect that we will need to force a compositor layer whenever the blur is applied. This is similar to opacity where because the shader relies on colors from the buffer it will require a rendering pass when applied to multiple layers. Right now opacity is in this strange state where we force a stacking context when it's not 1 but this is often surprising for developers as the stacking order of items changes when you start animations or change opacity. I think always flattening would be less surprising.

[AmeliaBR]

I suspect that we will need to force a compositor layer whenever the blur is applied.

No, to be clear, the proposal is that motion-blur could be ignored (no blur applied) if it's applied to an element that isn't a composited layer.

[css-meeting-bot]

The CSS Working Group just discussed motion blur.

The full IRC log of that discussion

<emilio> topic: motion blur
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3837
<emilio> argyle: motion blur is a pretty standard animation strategy
<emilio> ... it can add a nice polish, and in my experience I got requested to introduce motion blur in a bunch of places but I couldn't
<emilio> ... so I wrote a spec and introduced and try to get interest
<emilio> ... it'd only work on accelerated layers and the engine would track what to move and what not
<emilio> ... and it's something you cannot get with other blurs and only the graphics engine can do
<emilio> ??: I love this idea, go for it
<emilio> argyle: (describes the syntax)
<astearns> s/??/chris/
<emilio> ... we added two properties, motion-rendering (since we may want other effects in the future), and motion-shutter-angle, so avoid blurriness if stuff is moving too fast for example
<emilio> AmeliaBR: we did have discussion in the issue about potential simplifications so what we have no is "you turn blur at a default value", or an explicit request of not, and one of the things that we thought would be a restruction of this it'd be that it doesn't have side effects (doesn't create stacking contexts / containing blocks)
<emilio> ... another thing is that it doesn't need to be restricted to transform motion, but also scrolling and such
<emilio> ... maybe we'd want to determine whether to blur one or not the other
<emilio> astearns: I don't think the "doesn't force layers" is the right thing for authors
<emilio> AmeliaBR: that means we can't force defaults
<emilio> myles_: the UA knows what's moving
<emilio> ... right now this is unimplementable on WebKit
<emilio> ... if we did we'd do it in CoreAnimation
<emilio> ... and it'd be a default in the platform
<emilio> ... I think we all agree that motion blur is better
<emilio> ... so if browsers want to implement motion-blur they should just do that
<emilio> flackr: I think that not everything that moves can be blurrable, you may animate properties that depend on layout
<emilio> myles_: and perf would be terrible, that's a non-starter
<AmeliaBR> s/can't force defaults/can't use auto as a default, because it would also have the side effects/
<myles_> I don't understand why this has to be configurable
<AmeliaBR> q?
<emilio> argyle: It'd be interesting if the UA stylesheet would have it as a default, and that would require not changing side-effects
<emilio> AmeliaBR: so re. whether it should be configurable, I think it may not always so performant and some things are more important to blur than others, and there may be use-cases for not having motion blur
<astearns> ack dbaron
<emilio> myles_: I think the engine could have different heuristics, you probably dont' want to blur scrolling with texts
<emilio> dbaron: I think the point about animations that depend on layout or otherwise don't run in the compositor is interesting
<emilio> dbaron: if we really are going to want interop, there's a bunch of animations which you cannot define in terms of pixel moving
<emilio> ... and there's a bunch of intermediate edge-cases around
<emilio> ... you may think you're moving pixels, but it may not hit the compositor in some or other browsers
<emilio> ... so depending how much interop we need on this figuring out when it needs to apply may be pretty complicated
<emilio> flackr: I think that's why the proposal says it's optional, we probably don't need a lot of interop here
<emilio> AmeliaBR: its name matches the other -rendering properties which are just requests to the UA
<emilio> ... another approach is defining it as a filter effect in which case it'd do all the compositor
<emilio> myles_: a spec can't say "do motion blur if you can", what about things like WebRender? a spec _has_ to be more clear than that
<emilio> AmeliaBR: I think that's why the only thing the spec says is that this property doesn't force a layer
<emilio> myles_: and then authors which don't know about stacking contexts are going to be surprised when it doesn't work most of the time
<emilio> myles_: right now if you put a blur on anything it works
<emilio> AmeliaBR: so is the mood of the room making it work like filter?
<emilio> astearns: it looks like so, but probably browsers should try to implement some sort of motion filter on their own by default, and see if the configurability is a requirement
<emilio> AmeliaBR: volunteers?
<emilio> ... I think then argyle is on their own to poke at the Chrome folks
<emilio> majidvp: one question: can you actually blur using two subsequent frames or do you need more frames?
<emilio> ... because that can have impact on implementability
<emilio> myles_: the topic of motion blur is under active academic research
<emilio> flackr: the proposal doesn't blur frames but blurring across the object's motion
<emilio> ... as far as I know we're not doing anything like this r/n but it could be done
<astearns> ack dbaron
<emilio> myles_: maybe we should delay putting this in a spec until there's at least one implementor interest
<emilio> dbaron: blurring something that isn't a stacking context / fixed-pos containing-block would be interesting
<emilio> AmeliaBR: (repeats the two proposals (1) making it work like filter and (2) only apply the blur only if it would not require side-effects)
<emilio> myles_: (2) cannot be the behavior because we can promote on demote stuff to layers however we want
<emilio> myles_: we'd break websites if they could rely on that
<emilio> astearns: so it'd be interesting to see which use cases can be covered with (1)
<emilio> ... and see whether it'd still achieve what the author wants
<emilio> iank_: one last point from our graphics engs. is that there if you're forced to promote these things to layers then running on out-of-memory is super-easy
<AmeliaBR> q?
<emilio> myles_: other option is "don't do the motion blur if you can't", and in that case having this in the system compositor may be the best option
<AmeliaBR> scribescribe: AmeliaBR
<AmeliaBR> emilio: The second proposed behavior (no side effects, only if possible) that's not enough. There are compositor layers that also have fixed pos children. But forcing a motion blur will be expensive computationally.
<emilio> AmeliaBR: so I think tasks are coming with a revised proposal where it forces the same side-effects as filter and such, and maybe try to get someone from chromes compositing team and try to gather interest

[argyleink]

From 2015, here's a nice motion blur effect (simulated with svg filter on x) https://tympanus.net/Tutorials/MotionBlurEffect/, feels nice

[argyleink]

was thinking last night that a shift in the proposal syntax could help shift some of the effort and expectation from the feature.

current proposal syntax:

.animated-layer {
  motion-rendering: blur; 
  motion-shutter-angle: 180deg; 
}

updated proposal syntax i was thinking about last night:

.animated-layer {
  transform-filter: motion-blur(180deg); 
  /* or maybe? */
  transition-filter: motion-blur(180deg);
}

what i like is that ambiguity is gone due to more specific syntax: transform-filter sounds specific to transform properties (which i still feel is the best place to attack/solve first). folks wont be curious why theres no motion blur on their left/top/height/width/padding etc animations. this updated proposal limits the scope of the feature, and that's what i'm curious about, is what would it exclude that was included in the more general syntax?

[AmeliaBR]

transform-filter: motion-blur(180deg);

This syntax suggests that there are other types of transform-filters that will be added. What else are you considering? Cartoon effects like squash & stretch?

[argyleink]

yep, from the above thread folks have expressed desire to leave the syntax open to effects other than motion blur, which influenced the syntax to its current state of motion-rendering. yep, like squash and stretch, smear, etc.

another value add of this adjustment to transform-filter is that you could compose filter effects like we can today. could be something like:

transform-filter: motion-smear(10%) motion-blur() pixelate(50%);

i'm making things up in there, but that's what's nice, future additions can show up and travel down a paved path.

[surma]

One consideration I would like to add: Shutter angle alone will make the motion blur inherently frame rate dependent and therefore potentially device specific. We know that most devices run at 60fps, but there are some 90Hz, 120Hz or even 400Hz screens out there. Just defining a shutter angle and using the device’s native frame rate will yield drastically different visuals depending on the screen they are shown on.

Another side of the same coin: Motion blur is often used to achieve a certain aesthetic. For example, there is the concept of “cinematic” motion blur, which is what you get when you shoot a movie at ~25fps with a shutter angle of 180deg. That aesthetic is unachievable if you can’t define a target frame rate.

I’d love for this proposal to somehow solve this. I am not sure if just defining a target “emulated” frame rate would be sufficient or if it would just make things look weirder. I do know that some modern digital cameras are able to shoot at 60fps and add “cinematic” motion blur as a post-processing step. I’d love to get some insight from someone with cinematography knowledge here.

[jakearchibald]

Couple of thoughts:

What happens if a child and parent animates? <div><div></div></div> - If the outer div translates one way, and the inner div translates the other way, so the inner div appears static on the page, what does the motion blur look like?

Maybe transform-style (or something like that) can give us the option to treat the element like a surface or that the element interact in the same 'scene'.

If the animation loops, does the element blur from its end position to its start position? Eg:

• Element animates from out-of-view left to out-of-view right - you wouldn't want a blur of the item zipping back across the screen
• Element animates one turn - you'd expect motion blur throughout the animation (so the loop isn't noticeable), but you wouldn't expect the blur to be from 1 turn back to 0 turns.
• Imagine an element with a background that repeats every 200px. It covers the screen + 200px on the x axis. The animation translates -200px then loops. Right now this would look like a smooth continuing animation, but I can't see how you'd add motion blur here.

What happens with stepped animations? Would they blur at all?

[jakearchibald]

You could deal with the looping cases by getting the developer to provide keyframes beyond the start and end of the animation:

@keyframes square-spin {
  -100% { transform: rotate(-0.25turn); }
  from { transform: rotate(0turn); }
  to { transform: rotate(0.25turn); }
  200% { transform: rotate(0.5turn); }
}

In this case a solid square rotates in a way that looks constant, even though it's only rotating 1/4. By providing -100% and 200% values, the blur would look convincing.

Edit: If the user doesn't provide these out-of-bound values, I suppose the browser could figure it out if the easing is declarative. But it feels like there are cases where it might not be possible, eg with animation worklets, and path-based animations.

[argyleink]

looks like Lottie is trying to help folks get motion blur onto the web, they deliver the ux via wasm and a box blur. it's not that great of quality, and comes with some baggage, but has motion designers around me excited.

https://github.com/google/skia/commit/5f1108ce4669f3eae133fe015b2b843ec1c5fbec

[fmalita]

@argyleink the Skottie implementation linked above is not based on box blur, but on frame averaging: we sample multiple frames on the timeline and compute the result my modulating/blending these frames. You can see the effect in action here: https://skottie.skia.org/718e3d0979791b0c268efe68c10056a6?h=500&w=500

This is pretty close to the physical model, and also what AE appears to be doing (there's a separate Pixel Motion Blur effect which computes inter-frame per-pixel motion vectors, but this is about the basic MB switch).

This approach has a couple of nice properties:

• doesn't require prior animation/transform knowledge
• doesn't require/assume static content (adapts to content changes naturally)

The downside is obviously a multi-frame buffering requirement.

[argyleink]

pasting this here as another reference https://www.motionblurjs.com/

i particularly was interested in the distinction between motion blur vs motion fade

[argyleink]

here's motion blur mocked with some animated box shadow trickery https://codepen.io/michellebarker/pen/povdXRW