1399268 - Transparent "seams" (perhaps for triangulation edges?) along 3D transformed surface

Status: RESOLVED DUPLICATE of bug 1339664

(Core :: Graphics, defect, P2)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Load https://bugzilla.mozilla.org/attachment.cgi?id=8638364 (testcase from bug 1187209)

 2. Look for "seams" along otherwise solid-color faces.

 3. (optional) try zooming in/out.

ACTUAL RESULTS:
There are visible seams along the wide outer face of the blue block in the bottom row and the white block in the second-to-top row  (on the left face of the cube).

EXPECTED RESULTS:
No seams.


This is a regression from bug 1323797.  (At least with respect to the blue block on the bottom row.  The white block in the second-to-top row didn't show up correctly -- seams or no seams -- until after bug 1323797 landed.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot from before this regressed (no seams)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of bug (seams!)

Comment 3

[Daniel Holbert [:dholbert]]

Miko, do you know if this is already tracked somewhere, and is there anything we can do about it?

Comment 4

[Miko Mynttinen]

(In reply to Daniel Holbert [:dholbert] from comment #3)
> Miko, do you know if this is already tracked somewhere, and is there
> anything we can do about it?

I think the problem is antialiasing artifacts along the split seam. There is a relevant bug 1339664 filed for software backend, where I explicitly disabled AA when rendering split geometry.

On which platform is this, and do you have hardware acceleration enabled?

Comment 5

[Daniel Holbert [:dholbert]]

This is on Linux, 57.0a1 (2017-09-12) (64-bit)

I forget how to check for hardware accel, but it looks like it's disabled -- about:support says:
> AzureCanvasAccelerated   0
> AzureCanvasBackend       skia
> AzureContentBackend      skia
> HW_COMPOSITING           blocked by default: Acceleration blocked by platform
> OPENGL_COMPOSITING       unavailable by default: Hardware compositing is disabled

Comment 6

[Daniel Holbert [:dholbert]]

The seams do go away if I set the about:config pref "layers.acceleration.force-enabled" to true.  So HW acceleration does seem to avoid this.

Comment 7

[Miko Mynttinen]

(In reply to Daniel Holbert [:dholbert] from comment #5)
> This is on Linux, 57.0a1 (2017-09-12) (64-bit)
> 
> I forget how to check for hardware accel, but it looks like it's disabled --
> about:support says:
> > AzureCanvasAccelerated   0
> > AzureCanvasBackend       skia
> > AzureContentBackend      skia
> > HW_COMPOSITING           blocked by default: Acceleration blocked by platform
> > OPENGL_COMPOSITING       unavailable by default: Hardware compositing is disabled

This is very interesting, I would have expected Skia backend to work due to disabled AA.

I will investigate this next week, when I have my Linux machine at hand.

Comment 8

[Miko Mynttinen]

I am able to reproduce this on MacOS with hardware acceleration disabled.
It's very interesting that zooming in/out changes how the seams appear. This might be a rounding or accuracy problem with the layer coordinates.

Changing AA setting didn't seem to help.

Comment 9

[Miko Mynttinen]

Attachment: seam-reduced.html

Comment 10

[Miko Mynttinen]

Attachment: zoom.html

Comment 11

[Miko Mynttinen]

I investigated this further and managed to create a reduced testcase (seams-reduced.html). A curious thing with this test case is that the seam appears even when there are no intersections.
The second testcase (zoom.html) shows seams near the tile borders when zooming in.

Comment 12

[Miko Mynttinen]

Attachment: Bug 1399268 - Disable filtering during Draw3DTransformedSurface() when layer was split

Review commit: https://reviewboard.mozilla.org/r/189470/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/189470/

Comment 13

[Miko Mynttinen]

It seems that the source for the seams is filtering Skia uses in Draw3DTransformedSurface(). Unfortunately disabling this requires more fuzziness with preserves3d-nested.html.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8918644 [details]
Bug 1399268 - Disable filtering during Draw3DTransformedSurface() when layer was split

https://reviewboard.mozilla.org/r/189470/#review195524

::: commit-message-196da:2
(Diff revision 1)
> +Bug 1399268 - Disable filtering during Draw3DTransformedSurface() when layer was split
> +

What's the user visible impact of this change?

Comment 15

[Miko Mynttinen]

Attachment: with_filtering.png

Comment 16

[Miko Mynttinen]

Attachment: without_filtering.png

Comment 17

[Miko Mynttinen]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #14)
> Comment on attachment 8918644 [details]
> Bug 1399268 - Disable filtering during Draw3DTransformedSurface() when layer
> was split
> 
> https://reviewboard.mozilla.org/r/189470/#review195524
> 
> ::: commit-message-196da:2
> (Diff revision 1)
> > +Bug 1399268 - Disable filtering during Draw3DTransformedSurface() when layer was split
> > +
> 
> What's the user visible impact of this change?

I have attached screenshots showing the testcase with filtering turned on and off.

As this makes edges rather ugly, it might be worth it to also explore alternative solutions. Markus had an interesting idea to draw layers as rectangles and then clip them with a polygon path. Currently layers with attached geometry are rendered as filled paths.

Comment 18

[Jeff Muizelaar [:jrmuizel]]

Yeah. I think we'll want to explore better solutions than the ugliness.