Open Bug 866497 Opened 11 years ago Updated 10 months ago

Layer edges sometimes "clipping" 1px off content after switching SVG to use active layers

Categories

(Core :: Graphics: Layers, defect, P3)

defect

Tracking

()

People

(Reporter: jwatt, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [gfx-noted])

Attachments

(3 files)

Splitting this out from bug 839865. With the patch from that bug (just landed on inbound), there are sometimes 1px "clipping" issues at the edges of layers when they are active.

Cwiiis tells me that this may be a coverage issue when using the GPU to composite (or something like that).

Note that bug 861805 (stop layers from snapping transforms for SVG content) has landed. That didn't fix the issue, although it did in some cases change which edge got clipped.
Actually, I'm not sure how related that testcase is. Let me attach a better one.
In this testcase, all the rects should display the same. If layers.force-active is flipped to true, then they do not.

The top rect is the reference rect. The stroke-width is 2px (as it is for all the rects). Since the left and right edges are exactly in the middle of a pixel boundary, the left and right edge are blurred over 3 pixel columns rather than being sharp.

The second and third rects have a transform with a translate of {0,0}, purely to make them get a layer. Their half pixel offset is caused by the 'x' attribute having a .5 value. In fact the second rect has a .49 value, and it renders as expected. The third rect has a .5 value, and its left edge is "clipped".

The fourth and fifth rects have a transform with a translate of {0.49,0} and {0.5,0}, respectively (the x translation is an exact integer this time). The fourth rect has its left edge "clipped", whereas the fifth rect has its right edge "clipped".

The final sixth and seventh rects are just for comparison with the fourth and fifth rects, respectively. They are identical to their respective rect, except that the transform is applied to a containing <g> element that contains the test rect plus an extra padding rect designed to increase the bounds of the layer. This shows that they layer size being increased would get rid of the "clipping" at the edges of the fourth and fifth rects. (I'm not sure if that holds for the second and third rects because SVG does not provide equivalent facilities to do the offsetting with 'x' and apply a transform at the same time, so I can't test that.)
BTW, I hacked nsDisplayTransform::GetBounds locally to substantially increase the size of the bounds that it returns, but that doesn't increase the size of the layers that are created as I'd hoped (at least not as shown by paint flashing when the page is loaded), so I haven't yet confirmed that increasing the layer size would fix all these issues.
Hacking Layer::SetVisibleRegion to increase the size of the visible region "fixes" the comment 3 testcase...but then breaks a ton of actual tests by changing the size of things on the screen. I inflated the rect by 10 in all directions.
Using this simple testcase with MOZ_DUMP_PAINT_LIST=1:

For a 0.49 translation (when the left edge is clipped) I get:

OGLContainerLayer (0x113dc8000) [clip=(x=0, y=65, w=1166, h=643)]
                                [transform=[ 1 0; 0 1; 9.49 74; ]]
                                [visible=< (x=0, y=0, w=18, h=18); >]
  OGLThebesLayer (0x1226f6c00) [visible=< (x=0, y=0, w=18, h=18); >]
                               [isFixedPosition]
                               [valid=< (x=0, y=0, w=18, h=18); >]

And for a 0.5 translation (when the right edge is clipped) I get:

OGLContainerLayer (0x113b29800) [clip=(x=0, y=65, w=1166, h=643)]
                                [transform=[ 1 0; 0 1; 9.5 74; ]]
                                [visible=< (x=0, y=0, w=18, h=18); >]
  OGLThebesLayer (0x11f205000) [visible=< (x=0, y=0, w=18, h=18); >]
                               [isFixedPosition]
                               [valid=< (x=0, y=0, w=18, h=18); >]

This is the case regardless of whether the layers are active or not.

So it seems like FrameLayerBuilder is creating layers of the correct size and with the correct translation.
Blocks: 867599
Jonathan, is this bug still valid?
Whiteboard: [gfx-noted]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: