Blur filter animation artifacts |
|||||||
Issue descriptionAnimating blur filter sigma in ToT Chrome results in artifacts when radius is greater than 4px. This seems to be a result of the down sampling optimization skia uses for blur filters. This optimization kicks in when radius is 4px or greater. The attached html page reproduces this. It animates the blur radius from 2 to 6 px. Note that if running on a hiDPI device the optimization will kick in before 4px. This was discovered when trying to determine why layout tests produced significantly different results when moving the first level of this blur down sampling optimization to chrome for improved performance: https://chromium-review.googlesource.com/c/chromium/src/+/749308 The way we handle down-sampling in chrome using that patch doesn't result in the same artifacts and that's why the layout tests produce different results.
,
Jan 17 2018
Hi David, what is the artifact in the animation? Is that the transition not smooth (looks like down/up sampling does not restore the original shape?)
,
Jan 17 2018
,
Jan 17 2018
The size of the element will start to jump when the radius reaches 4px and the down sampling optimization kicks in. I noticed this as the blur optimization linked to in the description made these artifacts go away. With the optimization applied, the artifacts don't start appearing until we reach a 8px radius and skia's optimization is again needed.
,
Jan 17 2018
#4, just some random guess: all the skia down/up sampling are based on integers. So every level of down/up sampling will introduce some round error, such as 4px, 8px, etc.
,
Jan 17 2018
I'm not sure exactly what the correct fix is but the down-sampling is computed here: https://cs.chromium.org/chromium/src/third_party/skia/src/core/SkGpuBlurUtils.cpp?q=SkGpuBlurUtils.cpp&l=219 and https://cs.chromium.org/chromium/src/third_party/skia/src/core/SkGpuBlurUtils.cpp?q=SkGpuBlurUtils.cpp&l=276 and also takes the src offset into account. Looks like the rounding at the lowest down sampling level has some effect as the jump in size of the element is not just when blur radius passes one of the down sampling thresholds, but seems to align with the radius changes in physical pixels once we've passed the first down sampling threshold.
,
Jan 17 2018
,
Jan 17 2018
,
Jan 17 2018
I thought this was related to bug 795528 , but looking at it closer it seems like it is getting bigger and smaller. Bug 795528 would just have it shifting once at a very small blur size.
,
Jan 17 2018
Looks like this one has been here for a while. It's also likely specific to the GPU path. Bisect on Windows says: You are probably looking for a change made after 370522 (known good), but no lat er than 370531 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/b3db8caba11e68278131000999 b89df2d1ab44d5..db6584f5ba2d6cda49fa42775903399cd4d427d6
,
Jan 17 2018
Most likely my change https://chromium.googlesource.com/chromium/src/+/38858c57782f2a32cf4f93fcfcc35c340e665be4 "Accelerated filters should filter unpadded primitives".
,
Jan 19 2018
->Assigned since this has an owner.
,
Feb 7 2018
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by reve...@chromium.org
, Jan 17 2018