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

Fix some redundant cases of clip mask generation. #2115

Merged
merged 1 commit into from Nov 28, 2017

Conversation

@glennw
Copy link
Member

glennw commented Nov 28, 2017

There are two fixes here:

  • Image pictures were generating clip masks, but they are never
    actually used. In the future, we might want to support this,
    but at the moment it just results in clip masks that are then
    never used.
  • If a primitive is in the root coordinate system, then we know
    that it is axis-aligned, and that there are no coordinate
    system changes in between this primitive and the root. In that
    case, we can infer that the local_clip_rect of the clip scroll
    node will correctly handle the screen space clip rect.

In Gecko with the current WR code, I was seeing a lot of very large
clip masks being generated (4x extra A8 render targets) on HN. The
test case included here is a very reduced test case for these issues.

The test case makes use of the new reftest annotations to assert
that no alpha targets get allocated while rendering the yaml file.


This change is Reviewable

@glennw
Copy link
Member Author

glennw commented Nov 28, 2017

PS: In manual testing, this does appear to greatly reduce the amount of redundant clips masks (though there are still quite a few) on many web pages.

@glennw
Copy link
Member Author

glennw commented Nov 28, 2017

Even with this change, I'm still seeing heaps of clip masks being drawn when I wouldn't expect there to be. I don't have a good repro yet - I'll try to track this down more tomorrow.

@glennw
Copy link
Member Author

glennw commented Nov 28, 2017

Gecko try run above looks green.

Copy link
Member

mrobinson left a comment

Nice! Just a couple nits, but this looks fine to me.

};
(Some((pic.pipeline_id, mem::replace(&mut pic.runs, Vec::new()), rfid)), pic.cull_children)
(Some((pic.pipeline_id, mem::replace(&mut pic.runs, Vec::new()),rfid)),

This comment has been minimized.

@mrobinson

mrobinson Nov 28, 2017

Member

Nit: Missing space in "Vec::new()),rfid"

items:
-
bounds: [0, 111, 1887, 1365]
"clip-rect": [0, 111, 1887, 1365]

This comment has been minimized.

@mrobinson

mrobinson Nov 28, 2017

Member

It might be worth leaving a comment here explaining why this test doesn't generate any clip masks.

@mrobinson
Copy link
Member

mrobinson commented Nov 28, 2017

This does suggest that there is another bug. If the locally clipping of the layer is taking effect, we probably shouldn't see the outer rectangle of the clip shrinking at all. I'll investigate this today.

There are two fixes here:
 * Image pictures were generating clip masks, but they are never
   actually used. In the future, we *might* want to support this,
   but at the moment it just results in clip masks that are then
   never used.
 * If a primitive is in the root coordinate system, then we know
   that it is axis-aligned, and that there are no coordinate
   system changes in between this primitive and the root. In that
   case, we can infer that the local_clip_rect of the clip scroll
   node will correctly handle the screen space clip rect.

In Gecko with the current WR code, I was seeing a lot of very large
clip masks being generated (4x extra A8 render targets) on HN. The
test case included here is a very reduced test case for these issues.

The test case makes use of the new reftest annotations to assert
that no alpha targets get allocated while rendering the yaml file.
@glennw glennw force-pushed the glennw:fix-clips-more branch from d23c1c6 to 5f0aee1 Nov 28, 2017
@glennw
Copy link
Member Author

glennw commented Nov 28, 2017

Thanks, fixed up those nits. I do think there's another bug, like you said - since I see a lot of redundant clip masks still after this patch. If you want to hold off on merging this until you investigate and see if the bug fix also covers these issues, that's fine with me. Otherwise, we can merge this and revert if we find a better solution.

@mrobinson
Copy link
Member

mrobinson commented Nov 28, 2017

@glennw I think it's better to merge this ASAP, since it's unclear how much work it will be to fix the deeper issue.

@mrobinson
Copy link
Member

mrobinson commented Nov 28, 2017

@bors-servo
Copy link
Contributor

bors-servo commented Nov 28, 2017

📌 Commit 5f0aee1 has been approved by mrobinson

@bors-servo
Copy link
Contributor

bors-servo commented Nov 28, 2017

Testing commit 5f0aee1 with merge e30886d...

bors-servo added a commit that referenced this pull request Nov 28, 2017
Fix some redundant cases of clip mask generation.

There are two fixes here:
 * Image pictures were generating clip masks, but they are never
   actually used. In the future, we *might* want to support this,
   but at the moment it just results in clip masks that are then
   never used.
 * If a primitive is in the root coordinate system, then we know
   that it is axis-aligned, and that there are no coordinate
   system changes in between this primitive and the root. In that
   case, we can infer that the local_clip_rect of the clip scroll
   node will correctly handle the screen space clip rect.

In Gecko with the current WR code, I was seeing a lot of very large
clip masks being generated (4x extra A8 render targets) on HN. The
test case included here is a very reduced test case for these issues.

The test case makes use of the new reftest annotations to assert
that no alpha targets get allocated while rendering the yaml file.

<!-- 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/2115)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Nov 28, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: mrobinson
Pushing e30886d to master...

@bors-servo bors-servo merged commit 5f0aee1 into servo:master Nov 28, 2017
4 checks passed
4 checks passed
Taskcluster (pull_request) TaskGroup: success
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
Copy link
Member

kvark left a comment

@glennw did you happen to run a gecko try push with this change?
nvm, I see it now :)

// we know that the local_clip_rect in the clip node
// will take care of applying this clip, so no need
// for a mask.
if prim_coordinate_system_id == CoordinateSystemId::root() {

This comment has been minimized.

@kvark

kvark Nov 28, 2017

Member

I don't fully understand why this is needed. Wouldn't the same apply to any axis-aligned coordinate system, which should already be handled?

This comment has been minimized.

@glennw

glennw Nov 28, 2017

Author Member

It doesn't seem to handle it - @mrobinson thinks there might be a deeper issue that he is looking into. If / when that's resolved we could hopefully remove this.

@@ -1476,7 +1490,7 @@ impl PrimitiveStore {
(local_rect, xf_rect.bounding_rect)
};

if !self.update_clip_task(
if perform_culling && may_need_clip_mask && !self.update_clip_task(

This comment has been minimized.

@kvark

kvark Nov 28, 2017

Member

It doesn't appear obviously correct to me that we move the perform_culling check before the update_clip_task. This will result in stale metadata.screen_rect and metadata.clip_task being present in the rendered primitives.

This comment has been minimized.

@glennw

glennw Nov 28, 2017

Author Member

perform_culling is effectively a constant - it never changes from initial value. Therefore, the clip task will never be set, and the screen rect should only depend on the previous culling values, not part of the clip stack.

@glennw glennw deleted the glennw:fix-clips-more branch Nov 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.