Background filters bleed black (from outside the bounds of the viewport?) |
||||||||||||||||||||||||||
Issue descriptionAfter https://codereview.chromium.org/2089753003/, this becomes obvious, since it removes alpha from the backbuffer in the pixel tests. This represents our current behaviour in production. Previously this was hidden in the test since it was bleeding transparent into the filtered texture instead of black.
,
Jun 22 2016
,
Jun 22 2016
,
Jun 29 2016
,
Oct 5 2016
If this one is available, I would like to work on it.
,
Oct 5 2016
Please feel free. I don't think jaydasika is currently working on it based on its status.
,
Oct 5 2016
That's right, I am not working on this currently. Feel free to take it.
,
Oct 5 2016
Just to double check, but which css property is being affected? Is it 'backdrop-filter' or just a regular blur in a 'background-image'? I tried to reproduce the issue with the test case (http://codepen.io/Savago/pen/bwYPxR) in Linux with current master, but it seems ok (see attached).
,
Oct 5 2016
Background filters are backdrop-filters in CSS. It needs to be near the edge of the surface, as it's bleeding black from outside the surface. I can reproduce it with your codepen when I turn on --enable-experimental-web-platform-features. It bleeds from outside the viewport, so it's easier to see if you move both of the boxes to the right 1000px and increase the blur size. Then as you resize the window and the right edge approaches the blue box, the right edge of the box gets darker.
,
Oct 5 2016
http://codepen.io/anon/pen/GjydGr was my modified codepen (tho it will expire)
,
Oct 5 2016
body { overflow: hidden; } helps make it more obvious too.
,
Oct 5 2016
http://codepen.io/anon/pen/KgkRAE has that fwiw.
,
Oct 5 2016
@danakj Thanks for the promptly feedback, using the updated test case and resizing the Window, I can see that the blue div will darken as the window edge comes closer to it. Attached a screenshot of both states.
,
Oct 6 2016
Great. Maybe senorblanco@ might have some thoughts about how to work around this with GL if you're not sure what to try.
,
Nov 8 2016
,
Apr 25 2017
As it no longer looks like this is being worked on, do you mind if I take over ownership and work on this bug?
,
Apr 25 2017
Sure, feel free to claim.
,
Apr 25 2017
Yeah please feel free to take it. I couldn't work on it as I have being busy optimizing PNG decoding on ARM: https://bugs.chromium.org/p/chromium/issues/detail?id=687631#c38
,
Apr 25 2017
,
Apr 26 2017
Thanks!
,
May 12 2017
Dropped the bug.
,
May 12 2017
,
May 15 2017
Issue 659501 has been merged into this issue.
,
May 15 2017
Note this breaks support.apple.com. See crbug.com/659501 .
,
May 15 2017
It's very likely that the texture being handed to Skia for filtering is padded with black, and that black is being "pulled in" via SkBlurImageFilter. Some possible fixes: 1) Don't do that: crop the texture being handed to Skia to include only the relevant primitives. 2) Change background filters to use the makeWithFilter() fast-path, which also allows a subset rect to be passed. This will have the side-effect of improving performance. (Note that setting a clip rect won't help, since Skia filters internally expand the clip rect by the filter margins. This is by design, so that tiling via clip rect works correctly without introducing seams.)
,
May 15 2017
Related bug for idea #2 above: https://bugs.chromium.org/p/chromium/issues/detail?id=613233
,
May 28 2017
Tao, can you have a look at this as part of your investigation of Blur?
,
Jun 9 2017
Is this the same bug? I attached an image with full screen blur, but at the edge, we can see bleeding-black at the four edges.
,
Jun 9 2017
Yep thats this.
,
Jun 9 2017
#25, I will read "the makeWithFilter() fast-path". But I have a quick thought: can we change the behavior of skia to only use half window to calculate the blur or any filter at the edge? Or padding any outside viewport pixel by using the mirrored pixel? It will look better than padding with black.
,
Jun 9 2017
,
Jun 15 2017
I had tried several solutions, got the best so far. But still see a little on the bottom edge. Please see the attachment. Not sure why it is special than left and right edges. What I changed are: 1. Use kClamp_Mode in https://cs.chromium.org/chromium/src/third_party/skia/src/core/SkGpuBlurUtils.cpp?l=288 2. Do not useBounds in https://cs.chromium.org/chromium/src/third_party/skia/src/core/SkGpuBlurUtils.cpp?l=180 and https://cs.chromium.org/chromium/src/third_party/skia/src/core/SkGpuBlurUtils.cpp?l=182
,
Jun 15 2017
You definitely won't be able to remove the bounds from the left and right edges (note that these are also the top and bottom, for the vertical pass). This prevents us reading outside the valid region of the texture. And GL_CLAMP won't help in the general case, since it clamps to [0,1], and our bounds are probably a subregion of a power-of-2 scratch texture (e.g., 0, 0.8). However, it could be that, instead of skipping the texture access outside the bounds, we should be simply clamping the coordinate in the fragment shader to the bounds, and still doing the texture access and scale (it'll just be doing the same access multiple times -- not a big deal with texture caching, but we could also try something smarter if performance becomes relevant).
,
Jun 16 2017
,
Jun 19 2017
,
Jun 19 2017
I'm not sure why the downsampled image is 88x88, and not 100x100. That said, the borders of the image have alpha 255, and outside the border is transparent black (alpha 0), which seems correct. So it doesn't look seem the downsampling itself is introducing bleeding. You're saying, when you composite the resulting image at 1:1 pixel size (ie., to 88x88 screen pixels), there's bleeding? In that case, something is blending incorrectly or is not aligned over the pixel centers. It might be interesting to disable only the blur passes, and leave the downsample/upsample passes active, and see if you still get bleeding.
,
Jun 19 2017
Delete comment 36, it was caused by image viewer.
,
Jun 19 2017
#37, simple downsmaple will not generate the blurry. It was caused by the image viewer. The downsampled image is 88x88 may be because I returned too early and make it clipped at left/right. Attached an image without blur passes, only with 1x downsample and upsample. I can see the blurry due to interpolation. Because the background image is much smaller and totally inside the bounds. It seem there is no way to avoid this blurry at the background image edges. However, the alpha is 255 at the background image edges.
,
Jun 19 2017
In another case, if the background image is the same size as the bounds (200,200), when only do downsample and upsample, the alpha value at background image edges is about alpha=191.
,
Jun 19 2017
At a guess, it seems like we should be using a GrTextureDomainEffect in order to avoid bleeding during upsampling, in the same way that we do during the first pass of the downsample.
,
Jun 19 2017
Do we already use GrTextureDomainEffect [1]? https://cs.chromium.org/chromium/src/third_party/skia/src/core/SkGpuBlurUtils.cpp?l=273 robertphillips@ suggested use same-size filter of Gaussian blur for ChromeOS. senorblanco@, WDYT not expanding the filter? I am not quiet understand why expanding input rect by 3*sigma, how it is related to "so that tiling via clip rect works correctly without introducing seams". And I have not found the code, how to remove the expanded boundary and return or draw the correct sub-rect to final canvas or image. Could you please point it to me. Thanks.
,
Jun 19 2017
Yes, we use GrTextureDomainEffect for the first pass of the downsample. I'm suggesting we use it for the upsample as well. I'm not sure what you mean by "use same-size filter". Same as what? When filters are drawn tiled (we do this in GPU rasterization of SVG filters, for example), we need to expand the clip rect to accommodate for filter margins. So for blurs, we may need to grab pixels as far as 3*sigma away from the edge of the clip in order to produce the correct values on the boundary. This is what I was suggesting in #25: background filters may need to produce a source texture with more than the required size of the primitive, so that the pixels in the filter margin are correct. I don't know if we are or not (I didn't write the background filters code in CC).
,
Jun 19 2017
OTOH, if the texture that background filters is passing to Skia contains pixels you don't want in the result (ie., opaque black), you can use the CropRect on the SkBlurImageFilter to restrict it to that region (see the last param of SkBlurImageFilter::Make). Skia will never sample the input texture outside the CropRect.
,
Jun 20 2017
#44, it may not be the reason that input texture contains pixel we do not want. It seems due to the expanding of the clip rect so that Skia does interpolation of "out-bounds" pixels with value of 0. #43 "same-size" filter means for "do not expand the clip rect", which does not apply in the case you mentioned to grab pixels as far as 3*sigma away from edge. It seems there are two cases: 1. If we can provide pixels as far as 3*sigma away from the edge in the background texture, we can use current code. 2. If we cannot provide 3*sigma (say full screen texture already), we should clamp to the boundary of input texture? Should I add a parameter (flag) to choose what solution to apply or work on a general solution for both cases of 1 and 2? Another problem is that, chrome may not know if the texture can provide pixels of 3*sigma or not. If the gl_renderer.cc can know it, we might just pad the input before we pass it to Skia as senorblanco@ suggested. We may compare the unclipped_rect and the view_port_rect to determine this? danakj@, WDYT to pass Skia more texture if we might out of view_port after expand 3*sigma (blur radius in the layer()->SetBackgroundBlur(radius), we might need to change it, since the real_radius is 3*radius here), we just repeated pad with edge texture or reflected/mirrored texture? How efficient could it be?
,
Jun 20 2017
I don't think expanding the clip rect is the problem. The clip rect is *intersected* with the original primitive. So if your original primitive is the correct size and contains no extraneous pixels, clipping it with a 3*sigma rect should be a no-op. It should *only* have an effect if the original primitive (texture) is larger than the desired size and contains unwanted pixels. The clip rect is not the correct way to fix this. That's what the CropRect is for -- to crop out (or not sample) pixels in the source primitive. However, if that's not your problem (extraneous pixels), then neither one of these will work. I suspect you will still need to apply the texture domain to the upsampling, and to fix the blur passes to clamp the texture coords to the bounds before sampling, rather than effectively blending with transparent black.
,
Jun 20 2017
Right the problem is reading outside the bounds of the texture and treating that as black, not reading outside of some region within the texture. So GrTextureDomainEffect sounds like the right approach from what I read above.
,
Jun 20 2017
,
Jun 21 2017
Thanks every one.
I might get some desirable results and will upload a cl to skia for review.
The revised blur method will change some testing images. I am attaching some results for comparison.
The visualization of the images is not obvious, so I attach the analyze result from ImageMagick:
MAE: Mean absolute error.
Test 1:
compare -verbose -metric MAE background_filter_blur.png background_filter_blur_new_method.png null: 2>&1
Image: background_filter_blur.png
Channel distortion: MAE
red: 0 (0)
green: 0 (0)
blue: 0 (0)
all: 0 (0)
Test 2: (most difference)
compare -verbose -metric MAE background_filter_blur_outsets.png background_filter_blur_outsets_new_method.png null: 2>&1
Image: background_filter_blur_outsets.png
Channel distortion: MAE
red: 18.3755 (0.000280392)
green: 27.1777 (0.000414706)
blue: 18.3755 (0.000280392)
all: 21.3096 (0.000325163)
Test 3:
compare -verbose -metric MAE background_filter_blur_off_axis.png background_filter_blur_off_axis_new_method.png null: 2>&1
Image: background_filter_blur_off_axis.png
Channel distortion: MAE
red: 0.199175 (3.03922e-06)
green: 0.199175 (3.03922e-06)
blue: 0.199175 (3.03922e-06)
all: 0.199175 (3.03922e-06)
,
Jun 21 2017
Uploaded a cl at: https://skia-review.googlesource.com/c/20465/
,
Jun 26 2017
Uploaded a GM image test for the baseline of new logic: https://skia-review.googlesource.com/c/20778/
,
Jun 27 2017
The following revision refers to this bug: https://skia.googlesource.com/skia/+/0dc1f4f4cd1fa2ca091c79797608c5464c106bcb commit 0dc1f4f4cd1fa2ca091c79797608c5464c106bcb Author: wutao <wutao@google.com> Date: Tue Jun 27 11:37:26 2017 Add GM image test for blur with clamp mode. Adding a GM (Golden Master) image test in Skia to reproduce the bleed black issue in Chrome. This would allow regressions to be caught in Skia's status page before being rolled into Chrome. Bug: 622128 Change-Id: Ifd2824fff59483c8e4be48392ba467414d41ca13 TEST=imageblurclampmode.cpp Reviewed-on: https://skia-review.googlesource.com/20778 Commit-Queue: Robert Phillips <robertphillips@google.com> Reviewed-by: Robert Phillips <robertphillips@google.com> [modify] https://crrev.com/0dc1f4f4cd1fa2ca091c79797608c5464c106bcb/gn/gm.gni [add] https://crrev.com/0dc1f4f4cd1fa2ca091c79797608c5464c106bcb/gm/imageblurclampmode.cpp
,
Jun 29 2017
Added a Repeat_Mode to blur, here is a test image:
,
Jun 30 2017
The following revision refers to this bug: https://skia.googlesource.com/skia/+/039a7c70cea29aa40c4fb880b0d6bb523d449568 commit 039a7c70cea29aa40c4fb880b0d6bb523d449568 Author: wutao <wutao@google.com> Date: Fri Jun 30 18:11:16 2017 Added new edge handling mode (clamp and repeat) to Gaussian blur filter. Gaussian blur filter will interpolate value by using out of bounds coords, which is 0. This makes it appears darker near the bounds in the blurred images. There are two issues: 1) when downsampling and upsampling, we should use GrTextureDomainEffect kClamp_Mode to clamp the texture coords to the bounds; 2) during Gaussian blur, we need to clamp to texture bounds. BUG=622128 TEST=cc_unittests, GM image test & manual. Some test results can be found at: https://bugs.chromium.org/p/chromium/issues/detail?id=622128#c49 Change-Id: I9283da1d91efb0da94a991f2d372e9f62c288bdc Reviewed-on: https://skia-review.googlesource.com/20465 Commit-Queue: Robert Phillips <robertphillips@google.com> Reviewed-by: Stephen White <senorblanco@chromium.org> Reviewed-by: Robert Phillips <robertphillips@google.com> Reviewed-by: Mike Reed <reed@google.com> [modify] https://crrev.com/039a7c70cea29aa40c4fb880b0d6bb523d449568/src/effects/SkBlurMaskFilter.cpp [modify] https://crrev.com/039a7c70cea29aa40c4fb880b0d6bb523d449568/src/core/SkBlurImageFilter.cpp [modify] https://crrev.com/039a7c70cea29aa40c4fb880b0d6bb523d449568/src/core/SkGpuBlurUtils.cpp [modify] https://crrev.com/039a7c70cea29aa40c4fb880b0d6bb523d449568/src/core/SkGpuBlurUtils.h [modify] https://crrev.com/039a7c70cea29aa40c4fb880b0d6bb523d449568/gn/gm.gni [modify] https://crrev.com/039a7c70cea29aa40c4fb880b0d6bb523d449568/src/gpu/effects/GrGaussianConvolutionFragmentProcessor.cpp [modify] https://crrev.com/039a7c70cea29aa40c4fb880b0d6bb523d449568/gm/imageblurclampmode.cpp [modify] https://crrev.com/039a7c70cea29aa40c4fb880b0d6bb523d449568/include/effects/SkBlurImageFilter.h [add] https://crrev.com/039a7c70cea29aa40c4fb880b0d6bb523d449568/gm/imageblurrepeatmode.cpp [modify] https://crrev.com/039a7c70cea29aa40c4fb880b0d6bb523d449568/src/gpu/effects/GrGaussianConvolutionFragmentProcessor.h
,
Jun 30 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7cdac8bbf4615ebdd2822abbf34bb53c403d4741 commit 7cdac8bbf4615ebdd2822abbf34bb53c403d4741 Author: skia-deps-roller@chromium.org <skia-deps-roller@chromium.org> Date: Fri Jun 30 20:19:21 2017 Roll src/third_party/skia/ 9f183505a..6feb69123 (3 commits) https://skia.googlesource.com/skia.git/+log/9f183505acc9..6feb69123b11 $ git log 9f183505a..6feb69123 --date=short --no-merges --format='%ad %ae %s' 2017-06-30 ethannicholas SPIR-V comma operator support 2017-06-30 wutao Added new edge handling mode (clamp and repeat) to Gaussian blur filter. 2017-06-29 fmalita Delete non-raster-pipeline SkTwoPointConicalGradient impl Created with: roll-dep src/third_party/skia BUG=622128 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md If the roll is causing failures, see: http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium#TOC-Failures-due-to-DEPS-rolls CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel TBR=robertphillips@chromium.org Change-Id: I5c70bb49b9bc53fc7800ad11a86866337ba51f9c Reviewed-on: https://chromium-review.googlesource.com/558196 Reviewed-by: Skia Deps Roller <skia-deps-roller@chromium.org> Commit-Queue: Skia Deps Roller <skia-deps-roller@chromium.org> Cr-Commit-Position: refs/heads/master@{#483801} [modify] https://crrev.com/7cdac8bbf4615ebdd2822abbf34bb53c403d4741/DEPS
,
Jun 30 2017
Landed major changes in Skia. But there are some following Skia bugs to fix: https://bugs.chromium.org/p/skia/issues/detail?id=6827 https://bugs.chromium.org/p/skia/issues/detail?id=6826 Implement CPU backend for the new blur modes: clamp and repeat.
,
Jul 5 2017
,
Jul 5 2017
Submitted a cl to use new skia blur clamp mode in Chromium. https://chromium-review.googlesource.com/c/559935/ But there are some cases in blink does not need to use the new clamp code. Need to create a special code path to let ChromeOS to use the new clamp code?
,
Jul 5 2017
These tests should still use old skia code path: css3/filters/effect-blur-hw.html css3/filters/effect-brightness-clamping-hw.html css3/filters/effect-combined-hw.html css3/filters/filter-change-repaint-composited.html css3/filters/filter-repaint-composited-fallback-crash.html css3/filters/filter-repaint-composited-fallback.html
,
Jul 10 2017
Submit a cl to serialize the new TileMode in SkBlurImageFilterImpl. https://skia-review.googlesource.com/c/22079/
,
Jul 11 2017
The following revision refers to this bug: https://skia.googlesource.com/skia/+/da69944cbb9e561694716b8882d201d4f7f8790e commit da69944cbb9e561694716b8882d201d4f7f8790e Author: wutao <wutao@chromium.org> Date: Tue Jul 11 18:13:31 2017 Serialize the new TileMode in SkBlurImageFilterImpl. Serialize the new TileMode in SkBlurImageFilterImpl. And also update the SkReadBuffer::Version and CURRENT_PICTURE_VERSION in SkPicture. Bug: 622128 Change-Id: I3b04be2a36406227c6d8112e943d7415566c0c42 Reviewed-on: https://skia-review.googlesource.com/22079 Commit-Queue: Robert Phillips <robertphillips@google.com> Reviewed-by: Robert Phillips <robertphillips@google.com> Reviewed-by: Stephen White <senorblanco@chromium.org> Reviewed-by: Brian Salomon <bsalomon@google.com> [modify] https://crrev.com/da69944cbb9e561694716b8882d201d4f7f8790e/include/effects/SkBlurImageFilter.h [modify] https://crrev.com/da69944cbb9e561694716b8882d201d4f7f8790e/src/core/SkBlurImageFilter.cpp [modify] https://crrev.com/da69944cbb9e561694716b8882d201d4f7f8790e/include/core/SkPicture.h [modify] https://crrev.com/da69944cbb9e561694716b8882d201d4f7f8790e/src/core/SkReadBuffer.h
,
Jul 17 2017
,
Jul 19 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/174b91c83a9311a41cde43076c6d6e810f832fa3 commit 174b91c83a9311a41cde43076c6d6e810f832fa3 Author: wutao <wutao@chromium.org> Date: Wed Jul 19 20:35:45 2017 Use new Skia Blur Filter. Skia Blur image filter has a new mode to clamp pixels outside image to image edge. This can resolve the bleeding black issue at the bounds of texture. BUG=622128 TEST=manual tested with lock screen and new app launcher. Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Id13383910327882d61bd908bff51d2c3fdc36bb9 Reviewed-on: https://chromium-review.googlesource.com/559935 Commit-Queue: Tao Wu <wutao@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Reviewed-by: Stephen White <senorblanco@chromium.org> Reviewed-by: Robert Sesek <rsesek@chromium.org> Reviewed-by: Vladimir Levin <vmpstr@chromium.org> Cr-Commit-Position: refs/heads/master@{#487960} [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/cc/base/filter_operation.cc [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/cc/base/filter_operation.h [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/cc/base/render_surface_filters.cc [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/cc/ipc/filter_operation.mojom [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/cc/ipc/filter_operation_struct_traits.h [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/cc/trees/layer_tree_host_pixeltest_filters.cc [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/components/viz/test/data/background_filter_blur_off_axis.png [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/components/viz/test/data/background_filter_blur_outsets.png [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/components/viz/test/data/background_filter_rotated_gl.png [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/components/viz/test/data/blur_filter_with_clip_gl.png [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/skia/public/interfaces/BUILD.gn [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/skia/public/interfaces/OWNERS [add] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/skia/public/interfaces/blur_image_filter_tile_mode.mojom [add] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/skia/public/interfaces/blur_image_filter_tile_mode.typemap [add] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/skia/public/interfaces/blur_image_filter_tile_mode_struct_traits.h [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/skia/public/interfaces/test/struct_traits_unittest.cc [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/skia/public/interfaces/test/traits_test_service.mojom [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/skia/public/interfaces/typemaps.gni [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/ui/compositor/layer.cc [modify] https://crrev.com/174b91c83a9311a41cde43076c6d6e810f832fa3/ui/compositor/layer.h
,
Jul 25 2017
This bug should have been fixed. schenney@, for the "Experimental Web Platform features" bug 659501 , could you please take that one to use the new skia clamp mode in blur when where you need it?
,
Sep 18 2017
,
Jun 5 2018
There is still bleeding issue on Chrome with experimental web platform features enabled. For reference, MS Edge's backdrop-filter does not have the bleeding issue
,
Jun 5 2018
clintniglet1337@, I'm not seeing what the Edge/Chrome difference is. Could you explain? I think the bleeding has not been fixed in Chrome because we are not always using the new Skia feature. See bug 659501 .
,
Jun 5 2018
Responding to #67, the difference is in the shading on the lower edge of the blue rectangle. It shouldn't change color just bc it is clipped off/near the edge.
,
Oct 24
,
Nov 10
I can confirm that this bug still exists in Chrome 71, so I am re-opening it.
Here is a small repro, and a screenshot showing the edge pixels being blurred into the box.
<!DOCTYPE html>
<div class="box"></div>
<style>
.box {
position: absolute;
width: 100px;
height: 100px;
top: 0px;
left: 0px;
border: 1px solid blue;
-webkit-backdrop-filter: blur(30px);
backdrop-filter: blur(30px);
}
</style>
,
Nov 10
masonfreed@, I suggest to close this bug and open another one. As described in #64, Currently the skia clamp mode is only used in ChromeOS. --enable-experimental-web-platform-features is in blink, they should take over from here.
,
Nov 10
#71, we might just reuse bug 659501
,
Nov 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/01e30939a4710efa881c05fe91097c9596a8251a commit 01e30939a4710efa881c05fe91097c9596a8251a Author: Mason Freed <masonfreed@chromium.org> Date: Thu Nov 15 22:05:41 2018 Adding more layout/WPT tests for backdrop-filter These should reproduce (at least) these issues: - https://crbug.com/622128 - dark areas brought in from edges - https://crbug.com/632979 - dark areas brought in from edges - https://crbug.com/659501 - menus cause too much filtering - https://crbug.com/767997 - menus cause too much filtering - https://crbug.com/813796 - incorrect border used for filter - https://crbug.com/593307 - incorrect border used for filter Bug: 497522,622128, 632979 , 659501 , 767997 , 813796 , 593307 Change-Id: Iafea2fc8fffba950f74d27f21170df647dc62e29 Reviewed-on: https://chromium-review.googlesource.com/c/1330888 Commit-Queue: Mason Freed <masonfreed@chromium.org> Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Cr-Commit-Position: refs/heads/master@{#608537} [modify] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/TestExpectations [modify] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/css3/filters/backdrop-filter-basic-blur.html [modify] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/css3/filters/backdrop-filter-plus-filter-expected.html [modify] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/css3/filters/backdrop-filter-plus-filter.html [modify] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/external/wpt/css/filter-effects/backdrop-filter-basic-background-color.html [modify] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/external/wpt/css/filter-effects/backdrop-filter-basic-opacity.html [modify] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/external/wpt/css/filter-effects/backdrop-filter-basic.html [modify] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/external/wpt/css/filter-effects/backdrop-filter-border-radius.html [add] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/external/wpt/css/filter-effects/backdrop-filter-clip-rect-ref.html [add] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/external/wpt/css/filter-effects/backdrop-filter-clip-rect.html [add] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/external/wpt/css/filter-effects/backdrop-filter-edge-pixels-ref.html [add] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/external/wpt/css/filter-effects/backdrop-filter-edge-pixels.html [modify] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/external/wpt/css/filter-effects/backdrop-filter-isolation-isolate.html [modify] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/external/wpt/css/filter-effects/backdrop-filter-isolation.html [add] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/external/wpt/css/filter-effects/backdrop-filter-paint-order-ref.html [add] https://crrev.com/01e30939a4710efa881c05fe91097c9596a8251a/third_party/WebKit/LayoutTests/external/wpt/css/filter-effects/backdrop-filter-paint-order.html
,
Dec 14
|
||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||
Comment 1 by danakj@chromium.org
, Jun 22 2016