Closed
Bug 1058753
Opened 10 years ago
Closed 10 years ago
[CSS Filters] Add a test for a very large blur radius
Categories
(Core :: Graphics, defect)
Core
Graphics
Tracking
()
RESOLVED
FIXED
mozilla35
People
(Reporter: mvujovic, Assigned: mvujovic)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
(deleted),
patch
|
mstange
:
review+
mvujovic
:
checkin+
|
Details | Diff | Splinter Review |
It looks like we handle very large blur radii properly, but it'd be nice to have an automated test for them (e.g. "filter: blur(100000px)").
Comment 1•10 years ago
|
||
Firefox seems to freeze for me for such values.
Assignee | ||
Comment 2•10 years ago
|
||
(In reply to Tim Nguyen [:ntim] from comment #1)
> Firefox seems to freeze for me for such values.
Yeah, it hangs a bit for me too with large values.
Right now, we cap the blur radius to 500px. My 2011 MacBook Pro starts hanging noticeably at radii of 300px+, using software rendering. I haven't tested how the Windows D2D backend performs. Or mobile, for that matter.
Perhaps we should lower the cap, at least for software rendering? Markus, do you have any thoughts about this?
Flags: needinfo?(mstange)
Comment 3•10 years ago
|
||
I think lowering the cap for software filters is a good idea. We could have FilterNodeSoftware apply its own cap, by capping mStdDeviation in FilterNodeGaussianBlurSoftware::SetAttribute and FilterNodeDirectionalBlurSoftware::SetAttribute.
Flags: needinfo?(mstange)
Assignee | ||
Comment 4•10 years ago
|
||
This patch caps blur radii to 100px when rendering in software.
I added some tests to verify that directional and non-directional blurs are capped. However, I wasn't quite sure how to make the tests force software rendering of filters. I ended up with "skip-if(d2d) pref(layers.acceleration.disabled,true)", so the tests at least run on Mac and Linux, and the assumption is that layers will have to be accelerated for filter rendering to be accelerated (when that's implemented).
Here are some perf results I used to choose a cap of 100px. I blurred a 1000x1000 solid colored div:
Macbook Pro Mid 2010, Firefox Nightly 34.0a1 (2014-09-02)
Blur radius / Time
10px => 64ms
50px => 98ms
100px => 155ms
200px => 320ms
300px => 514ms
400px => 4066ms (OS X shows beachball)
500px => 5680ms (OS X shows beachball)
Nexus 7, Firefox 32:
10px => 2118ms
50px => 6004ms
100px => 13646ms
Arguably, we could still go lower because it still takes 13 seconds to render a 100px blur on mobile, but I'm worried that's capping it fairly low.
Attachment #8483056 -
Flags: review?(mstange)
Comment 5•10 years ago
|
||
Comment on attachment 8483056 [details] [diff] [review]
Patch
Sounds good to me.
Attachment #8483056 -
Flags: review?(mstange) → review+
Assignee | ||
Comment 6•10 years ago
|
||
Comment on attachment 8483056 [details] [diff] [review]
Patch
https://hg.mozilla.org/integration/mozilla-inbound/rev/3ec65eb63c17
https://tbpl.mozilla.org/?tree=Try&rev=329096e4b380
Attachment #8483056 -
Flags: checkin+
Comment 7•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Updated•10 years ago
|
Flags: qe-verify-
You need to log in
before you can comment on or make changes to this bug.
Description
•