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)
Core
Graphics: Layers
Tracking
()
NEW
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.
Reporter | ||
Comment 1•11 years ago
|
||
Reporter | ||
Comment 2•11 years ago
|
||
Actually, I'm not sure how related that testcase is. Let me attach a better one.
Reporter | ||
Comment 3•11 years ago
|
||
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.)
Reporter | ||
Comment 4•11 years ago
|
||
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.
Reporter | ||
Comment 5•11 years ago
|
||
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.
Reporter | ||
Comment 6•11 years ago
|
||
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.
Updated•6 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•