- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Jun 2019 20:22:00 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `motion blur`. <details><summary>The full IRC log of that discussion</summary> <emilio> topic: motion blur<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/3837<br> <emilio> argyle: motion blur is a pretty standard animation strategy<br> <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<br> <emilio> ... so I wrote a spec and introduced and try to get interest<br> <emilio> ... it'd only work on accelerated layers and the engine would track what to move and what not<br> <emilio> ... and it's something you cannot get with other blurs and only the graphics engine can do<br> <emilio> ??: I love this idea, go for it<br> <emilio> argyle: (describes the syntax)<br> <astearns> s/??/chris/<br> <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<br> <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)<br> <emilio> ... another thing is that it doesn't need to be restricted to transform motion, but also scrolling and such<br> <emilio> ... maybe we'd want to determine whether to blur one or not the other<br> <emilio> astearns: I don't think the "doesn't force layers" is the right thing for authors<br> <emilio> AmeliaBR: that means we can't force defaults<br> <emilio> myles_: the UA knows what's moving<br> <emilio> ... right now this is unimplementable on WebKit<br> <emilio> ... if we did we'd do it in CoreAnimation<br> <emilio> ... and it'd be a default in the platform<br> <emilio> ... I think we all agree that motion blur is better<br> <emilio> ... so if browsers want to implement motion-blur they should just do that<br> <emilio> flackr: I think that not everything that moves can be blurrable, you may animate properties that depend on layout<br> <emilio> myles_: and perf would be terrible, that's a non-starter<br> <AmeliaBR> s/can't force defaults/can't use auto as a default, because it would also have the side effects/<br> <myles_> I don't understand why this has to be configurable<br> <AmeliaBR> q?<br> <emilio> argyle: It'd be interesting if the UA stylesheet would have it as a default, and that would require not changing side-effects<br> <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<br> <astearns> ack dbaron<br> <emilio> myles_: I think the engine could have different heuristics, you probably dont' want to blur scrolling with texts<br> <emilio> dbaron: I think the point about animations that depend on layout or otherwise don't run in the compositor is interesting<br> <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<br> <emilio> ... and there's a bunch of intermediate edge-cases around<br> <emilio> ... you may think you're moving pixels, but it may not hit the compositor in some or other browsers<br> <emilio> ... so depending how much interop we need on this figuring out when it needs to apply may be pretty complicated<br> <emilio> flackr: I think that's why the proposal says it's optional, we probably don't need a lot of interop here<br> <emilio> AmeliaBR: its name matches the other -rendering properties which are just requests to the UA<br> <emilio> ... another approach is defining it as a filter effect in which case it'd do all the compositor<br> <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<br> <emilio> AmeliaBR: I think that's why the only thing the spec says is that this property doesn't force a layer<br> <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<br> <emilio> myles_: right now if you put a blur on anything it works<br> <emilio> AmeliaBR: so is the mood of the room making it work like filter?<br> <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<br> <emilio> AmeliaBR: volunteers?<br> <emilio> ... I think then argyle is on their own to poke at the Chrome folks<br> <emilio> majidvp: one question: can you actually blur using two subsequent frames or do you need more frames?<br> <emilio> ... because that can have impact on implementability<br> <emilio> myles_: the topic of motion blur is under active academic research<br> <emilio> flackr: the proposal doesn't blur frames but blurring across the object's motion<br> <emilio> ... as far as I know we're not doing anything like this r/n but it could be done<br> <astearns> ack dbaron<br> <emilio> myles_: maybe we should delay putting this in a spec until there's at least one implementor interest<br> <emilio> dbaron: blurring something that isn't a stacking context / fixed-pos containing-block would be interesting<br> <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)<br> <emilio> myles_: (2) cannot be the behavior because we can promote on demote stuff to layers however we want<br> <emilio> myles_: we'd break websites if they could rely on that<br> <emilio> astearns: so it'd be interesting to see which use cases can be covered with (1)<br> <emilio> ... and see whether it'd still achieve what the author wants<br> <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<br> <AmeliaBR> q?<br> <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<br> <AmeliaBR> scribescribe: AmeliaBR<br> <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.<br> <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<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3837#issuecomment-499652585 using your GitHub account
Received on Thursday, 6 June 2019 20:22:02 UTC