CSS blur effects are highly inefficient and very slow in canvas filters.
Reported by
thehairy...@gmail.com,
May 24 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce the problem: 1. Perform drawing calls in the canvas with the canvas filter set to use a moderate gaussian blur. 2. enjoy 1 fps What is the expected behavior? A reasonable framerate should be expected. What went wrong? The blurring algorithm used is very inefficient. Did this work before? No Does this work in other browsers? Yes Chrome version: 58.0.3029.110 Channel: stable OS Version: 10.0 Flash Version: Firefox doesn't perform that much better either but it does run at about 5-10 fps, It shouldn't really lag at all, it might make sense to take a look at the blurring algorithm in the libass open source subtitle renderer as it's been heavily optimized for performing high-speed gaussian blurs.
,
May 25 2017
thehairyrock@ - Thanks for filing the issue...!! Could you please provide a sample test file to test the issue from TE-end. This will help us in triaging the issue further. Thanks...!!
,
Aug 6 2017
sure, http://hbmp.us/hbmp_demo/blur_test.html demonstrates the problem, but I can whip up a simple test case of this issue.
,
Aug 6 2017
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 7 2017
It appears to be an issue with one of the possible rendering backends that chrome chooses from when running canvas2D as a simple test case does not reproduce the issue but profiling the complex case shows that the majority of the time is spent in the draw call being blurred, which suggests that the problem exists in whichever canvas2D implementation chromium is using for the complex case. here is the simple case test that works fine: https://jsfiddle.net/0vLruL2x/
,
Aug 7 2017
Seems more like a canvas or paint issue, redirecting to the canvas team.
,
Aug 7 2017
Here is a reduced-size version of the canvas: https://jsfiddle.net/0vLruL2x/1/ It shows the slowness. Basically, creating a canvas smaller than 256x256 forces Chrome to use the CPU rendering backend instead of the GPU-accelerated one. There are also other things that can trigger the CPU fallback based on some performance heuristics. It looks like the heuristics need to be tuned.
,
Aug 8
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 13
We should address this while changing the heuristics for canvas acceleration. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by nyerramilli@chromium.org
, May 25 2017