Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upUse the texture filtering hardware to reduce the number of sample operations in the blur shader. #3122
Conversation
|
Yeah, this looks bad. I'll try to match the existing rendering more closely. |
|
If then new blur is just as "correct" as the software reference blur, it's probably not worth making them match. It would be better to spend the time on making sure that WebRender is used for both the test and the reference (by making SVG filters go through WebRender.) |
I'm pretty confident this is correct--it's either just as accurate or more accurate than the current implementation--so it'll let me sort out which test failures, if any, from servo#3028 and servo#3122 are true regressions.
I'm pretty confident this is correct--it's either just as accurate or more accurate than the current implementation--so it'll let me sort out which test failures, if any, from servo#3028 and servo#3122 are true regressions.
Round blur support up to the nearest even number of pixels. I'm pretty confident this is correct--it's either just as accurate or more accurate than the current implementation--so it'll let me sort out which test failures, if any, from #3028 and #3122 are true regressions. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/3126) <!-- Reviewable:end -->
|
|
pcwalton
force-pushed the
pcwalton:blur-filtering
branch
2 times, most recently
from
4759586
to
58814ff
|
Much better now. Just one test has imperceptible differences, probably due to minor rounding differences introduced by algebraic manipulation. |
|
Just a few minor fuzziness differences on try. This looks good. r? @gw3583 |
|
complete! all files reviewed, all discussions resolved (waiting on 
|
Windows reftests are failing though. |
|
@pcwalton It looks like this was basically ready to go but then got overlooked. If that's the case, I guess rebasing and doing a try would be good to make sure it's still fine, and then we can get this merged? |
|
It was ready to go but I wasn't sure about try results. Let me try again. |
|
@pcwalton Did you get a chance to kick off another try for this? |
|
|
|
From a quick look at the try run:
I think these changes are fine, but we should get @staktrace or @jrmuizel to double check. Also looks like it needs a rebase to fix the conflicting reftest image. |
Yes although I don't see these failures anywhere else so I'd like to see another try push rebased on central to confirm. And this try push was actually based on mozilla-beta rather than mozilla-central, so it may not even be accurate in terms of what it shows.
Agreed, with the caveat that these results are from mozilla-beta. If we get the same results on mozilla-central that's fine. |
|
@staktrace Thanks for double checking those. @pcwalton Looks like we need a try run against m-c, and to fix the rebase conflict above, then this should hopefully be good to go. |
|
Try looks good (although will get @staktrace to double check again). Just need to resolve that conflicting png above then this is ready, I think. |
|
Yup, try push looks good to me (I can adjust the reftest numbers on those two tests when I merge it to m-c). |
|
Patch updated. |
|
@bors-servo r+ |
|
|
Use the texture filtering hardware to reduce the number of sample operations in the blur shader.
Linear filtering allows us to evaluate the formula
k₀c₀ + k₁c₁ (Equation 1)
where c₀ and c₁ are the colors of adjacent texels and k₀ and k₁ are arbitrary
factors (in this case, the results of evaluating the Gaussian function) with a
single lookup. Linear filtering evaluates the following expression for some t
between 0 and 1:
lerp(c₀, c₁, t)
It can be shown algebraically that Equation 1 is equivalent to:
⎛ k₁ ⎞
(k₀ + k₁)lerp⎜c₀, c₁, ───────⎟
⎝ k₀ + k₁⎠
Which can be readily evaluated by letting `t = k₁/(k₀ + k₁)` and performing a
texture lookup.
This results in some minor visual differences because we always compute an even
number of pixels on each side (i.e. the *support* is now always rounded up to
the nearest even number of pixels), whereas before we might have evaluated an
odd number of pixels. All differences should therefore be minor quality
improvements.
Don't merge this yet; I want to run tests and a try build.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/3122)
<!-- Reviewable:end -->
|
|
|
One of the reftest fails on Linux CI and will need fuzziness of ..... 1 pixel .... max difference 1 |
…rations in
the blur shader.
Linear filtering allows us to evaluate the formula
k₀c₀ + k₁c₁ (Formula 1)
where c₀ and c₁ are the colors of adjacent texels and k₀ and k₁ are arbitrary
factors (in this case, the results of evaluating the Gaussian function) with a
single lookup. Linear filtering evaluates the following expression for some t
between 0 and 1:
lerp(c₀, c₁, t)
It can be shown algebraically that Formula 1 is equivalent to:
⎛ k₁ ⎞
(k₀ + k₁)lerp⎜c₀, c₁, ───────⎟
⎝ k₀ + k₁⎠
Which can be readily evaluated by letting `t = k₁/(k₀ + k₁)` and performing a
texture lookup.
|
Updated. |
|
@bors-servo r=gw3583 |
|
|
Use the texture filtering hardware to reduce the number of sample operations in the blur shader.
Linear filtering allows us to evaluate the formula
k₀c₀ + k₁c₁ (Equation 1)
where c₀ and c₁ are the colors of adjacent texels and k₀ and k₁ are arbitrary
factors (in this case, the results of evaluating the Gaussian function) with a
single lookup. Linear filtering evaluates the following expression for some t
between 0 and 1:
lerp(c₀, c₁, t)
It can be shown algebraically that Equation 1 is equivalent to:
⎛ k₁ ⎞
(k₀ + k₁)lerp⎜c₀, c₁, ───────⎟
⎝ k₀ + k₁⎠
Which can be readily evaluated by letting `t = k₁/(k₀ + k₁)` and performing a
texture lookup.
This results in some minor visual differences because we always compute an even
number of pixels on each side (i.e. the *support* is now always rounded up to
the nearest even number of pixels), whereas before we might have evaluated an
odd number of pixels. All differences should therefore be minor quality
improvements.
Don't merge this yet; I want to run tests and a try build.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/3122)
<!-- Reviewable:end -->
|
|
…2b5ac5aeefe9 (WR PR #3122). r=kats servo/webrender#3122 Differential Revision: https://phabricator.services.mozilla.com/D13975 --HG-- extra : moz-landing-system : lando
…2b5ac5aeefe9 (WR PR #3122). r=kats servo/webrender#3122 Differential Revision: https://phabricator.services.mozilla.com/D13975
…2b5ac5aeefe9 (WR PR #3122). r=kats servo/webrender#3122 Differential Revision: https://phabricator.services.mozilla.com/D13975 UltraBlame original commit: 2a526099b1f4405dd3df6852d38d0666580f4542
…2b5ac5aeefe9 (WR PR #3122). r=kats servo/webrender#3122 Differential Revision: https://phabricator.services.mozilla.com/D13975 UltraBlame original commit: 2a526099b1f4405dd3df6852d38d0666580f4542
…2b5ac5aeefe9 (WR PR #3122). r=kats servo/webrender#3122 Differential Revision: https://phabricator.services.mozilla.com/D13975 UltraBlame original commit: 2a526099b1f4405dd3df6852d38d0666580f4542
pcwalton commentedSep 25, 2018
•
edited by larsbergstrom
Linear filtering allows us to evaluate the formula
where c₀ and c₁ are the colors of adjacent texels and k₀ and k₁ are arbitrary
factors (in this case, the results of evaluating the Gaussian function) with a
single lookup. Linear filtering evaluates the following expression for some t
between 0 and 1:
It can be shown algebraically that Equation 1 is equivalent to:
Which can be readily evaluated by letting
t = k₁/(k₀ + k₁)and performing atexture lookup.
This results in some minor visual differences because we always compute an even
number of pixels on each side (i.e. the support is now always rounded up to
the nearest even number of pixels), whereas before we might have evaluated an
odd number of pixels. All differences should therefore be minor quality
improvements.
Don't merge this yet; I want to run tests and a try build.
This change is