Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The horizontal blur pass sometimes seems to blur in garbage from the side #1943

Closed
mstange opened this issue Oct 25, 2017 · 9 comments
Closed

The horizontal blur pass sometimes seems to blur in garbage from the side #1943

mstange opened this issue Oct 25, 2017 · 9 comments
Assignees

Comments

@mstange
Copy link
Contributor

@mstange mstange commented Oct 25, 2017

https://bugzilla.mozilla.org/show_bug.cgi?id=1411693

Testcase (created by Darkspirit)

When hovering over the element on the page, the box-shadow sometimes has extra shadows on the right edges. Here are two screenshots with and without the glitch, and with gfx.webrender.debug.render-targets enabled:

good frame:
box-shadow-good-frame

bad frame:
box-shadow-bad-frame

You can see that in the bad frame, the render target in the middle has a box-shadow whose right edge is a bit brighter than in the good frame. It looks like the right edge got some stuff blurred in from beyond the right edge of the rectangle that is supposed to be sampling from.

@glennw
Copy link
Member

@glennw glennw commented Oct 26, 2017

I can reproduce this with a static box shadow that has a fractional blur radius. There must be somewhere in the code that ends up with a rounding error when a fractional blur radius is supplied. I'll work on a fix today.

@glennw
Copy link
Member

@glennw glennw commented Oct 26, 2017

Note to self: the blur radius is correctly rounded to device pixels, but the CSS space blur radius is retained as a float. Probably related to that.

@Darkspirit
Copy link

@Darkspirit Darkspirit commented Nov 1, 2017

This got better with the latest webrender update. (Thank you!) Those unwanted things on the right and bottom are gone and only a white flickering is left.

Commits between the previous and latest webrender update:
4b8493d...c0194de

@kvark kvark mentioned this issue Nov 17, 2017
6 of 6 tasks complete
bors-servo added a commit that referenced this issue Nov 21, 2017
DocumentAPI support on the Renderer side

This is a second batch of changes related to Document API, following #1509.

The idea is to allow Gecko to have separate documents for the chrome UI, page content, and bottom status bar, as opposed to using different pipelines in the same document. This change would allow minimal scene rebuilds per frame when UI is affected.

WIP TODO:
- [x] strict ordering API: 532bff5
- [x] Servo patch and test runs: kvark/servo@0263fa8
- [x] Firefox patch and try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f939fbdab0231e6328061c12903db0c45847dd18
  - ~~`box-shadow/boxshadow-skiprect.html`~~ (from #1943)
  - ~~`css-filter-chains/moz-element.html`~~ (same as in #2053)
  - ~~`transform/animate-layer-scale-inherit-1.html`~~ (from #2043)
- [x] example
- [x] `FrameBuilder` and `RenderedDocument` refactor
https://tools.taskcluster.net/groups/DEvThfCaQWmt5Hp806GDLg/tasks/VLCZI7hVTQCc1xrDR3PgOQ/details#
- [x] review comments

cc  @glennw  @mstange @jrmuizel

<!-- 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/2050)
<!-- Reviewable:end -->
@glennw glennw self-assigned this Feb 22, 2018
@Gankra
Copy link
Contributor

@Gankra Gankra commented Mar 9, 2018

@glennw any news on this?

@glennw
Copy link
Member

@glennw glennw commented Mar 9, 2018

@gankro Not specifically, although the recent work I've done on box-shadows should make this easier to fix / debug. It's also possible that it may have been fixed, but I'm guessing not, from your comment here?

@Gankra
Copy link
Contributor

@Gankra Gankra commented Mar 10, 2018

I was just following up on it since I vaguely recalled you mentioning this was going to be fixed soon. Just triaging some fuzziness that has been attributed to this.

@Darkspirit
Copy link

@Darkspirit Darkspirit commented Mar 10, 2018

Summary of bug 1411693 comment 18:
Probably #2471 made things far better. Testcase 2 shows the remaining problem more clearly. (Screencast)

@Darkspirit
Copy link

@Darkspirit Darkspirit commented Jun 10, 2018

@gw3583
Copy link
Collaborator

@gw3583 gw3583 commented Feb 1, 2019

This is resolved with the recent snapping fixes for clip masks.

@gw3583 gw3583 closed this Feb 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.