1768462 - We should probably clip child picture more tightly

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, task, P3)

Description

[Nicolas Silva [:nical]]

While investigating bug 1726388 I ran into something interesting with the wrench test reftests/clip/clip-and-filter-with-rotation.yaml. It's structure looks like this:

- rotation (10deg)
  - clip [0, 0, 324, 295]
    - filter
      - blue rect [-150, -150, 624, 624]
      - red rect [0, 0, 324, 295]

As far as I can tell, the way we render it is to create an off-screen picture the size of the blue rect, apply the filter and apply the rotation and clip when compositing the picture into the main pass with the image brush. The important part is that we don't clip the child picture which has two effects:

• we allocate and shade more pixels (that's not a big issue in this particular case)
• with the edge anti-aliasing (we are under a rotation), the image brush shader can sample half a pixel outside of the clip. In this test case it means a bit of the blue rect bleading through even though the entire clip area is covered by the red rect.

Today the test doesn't show the bleeding, and that's because of some buggy behavior with transformed pictures where we for the edge aa flags to be false (regardless of the rotation), leading to no edge inflation (so no sampling beyond the clip), but we still do anti-aliasing without the inflation getting only half of the aa pixels. I'm trying to fix that. In this case the rotation means we need proper AA which means the edges are inflated and we need one of the following things:

• Clip before sampling (clip the child pictures) so that the uv bounds being restricted to the render task also restrict to the clip.
• Set the render task up so that the restricted uv-bounds correspond to the clip area instead of the entire child picture.
• Accept the bleeding artifact.

I'm not entirely convinced that it's a big issue for real pages but the wrench test tries to enforce a specific behavior (no bleeding) and in principle I think that it would make sense to not have bleeding there.

I had a look at how this works internally, we have a clipped_local_rect in picture.rs which doesn't appear to be restricted to the clip in this case, it is the union of prim_clip_chain.pic_coverage_rect which also doesn't appear to be affected by the clip. I'm not sure how the latter gets computed or what it represents exactly.

Glenn, any thoughts? If clipping the child picture in this case is what we want, I'd love a few pointers about the details of how picture task sizes are computed and gotchas if any.

Comment 1

[Glenn Watson [:gw]]

I think there's probably too much in the way of subtle details to cover this via text (and I don't have the whole picture in my head right now). A video call at some point to work through the details might be better?

Comment 2

[Nicolas Silva [:nical]]

Sounds good to me.

Comment 3

[Glenn Watson [:gw]]

This should be fixed.