W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2019

Re: [csswg-drafts] [css-animation] Motion Blur (#3837)

From: Adam Argyle via GitHub <sysbot+gh@w3.org>
Date: Thu, 18 Apr 2019 23:34:15 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-484722974-1555630454-sysbot+gh@w3.org>
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 👍 


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](https://en.wikipedia.org/wiki/Twelve_basic_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.**

GitHub Notification of comment by argyleink
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3837#issuecomment-484722974 using your GitHub account
Received on Thursday, 18 April 2019 23:34:25 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:46 UTC