- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Thu, 18 Apr 2019 01:45:50 +0000
- To: public-css-archive@w3.org
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 add unidirectional blur to CSS shorthand](https://github.com/w3c/fxtf-drafts/issues/229)). 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.) -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3837#issuecomment-484323970 using your GitHub account
Received on Thursday, 18 April 2019 01:45:51 UTC