Black boxes on depth-of-field chrome experiment

VERIFIED FIXED in mozilla2.0b8

Status

()

defect
VERIFIED FIXED
9 years ago
8 years ago

People

(Reporter: sicking, Assigned: mstange)

Tracking

Trunk
mozilla2.0b8
x86
macOS
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: chromeexperiments, [qa!], )

Attachments

(4 attachments)

Steps to reproduce (for OSX 10.6.4):

1. go to http://mrdoob.com/projects/chromeexperiments/depth_of_field/
2. watch for a bit

After less than a minute I see a big black square appear for a few seconds on the right side of the page. After it disappears I see a few other, but smaller, artifacts.

Think this started happening since we turned on hardware acceleration on mac.
I can't seem to reproduce this again exactly as described in comment 0.

I do consistently see square-shaped artifacts, seemingly around the images that this page is drawing. However I can't reproduce the black box.

There are some artifacts with acceleration turned off, though to a much smaller extent.
blocking2.0: --- → ?
Posted image screenshot
That's a good one since you can see both types of artifacts.

A little bit above the middle about 20 pixels to the left of the black square is a short vertical line. Similarly alone the bottom is both a horizontal and a vertical line.

Oh, also the black square is quick visual ;)
Interesting! They exist on windows hardware accelerated layers too.
I can definitely reproduce on Mac, but the fact that it happens on Windows hw accel layers is very suspect. Timothy, can you take a look?
Assignee: nobody → tnikkel
blocking2.0: ? → betaN+
Happens on Windows without any hardware acceleration too.
There is a third type of artifact visible: when one of the balls is near the edge of the content area there is sometimes a white band visible on the edge of the content area where the ball should be drawn. That bug is caused by http://hg.mozilla.org/mozilla-central/rev/c888cdffd617 (bug 579276).
The other "lines" artifacts are caused by:
changeset:   48693:9a45bd27ec75
user:        Matt Woodrow <matt.woodrow+bugzilla@gmail.com>
date:        Mon Aug 02 15:07:04 2010 +1200
summary:     Bug 505115. Use layers to render active 2D transforms. r=roc,dbaron
The black boxes are hard to track down because they are rarer.

One thing I noticed is that if you save the page locally it fails to save the sprite png it uses to actually draw the balls, and you just get black boxes. (Restoring the sprite png locally makes it draw normally.) So maybe it is failing to get the image somehow?
I see a similar "ghost line" artifact on http://people.mozilla.com/~cjones/scale.html with GL compositing on mac (also fuzzy edges caused by resampling the temporary textures).  Should be easy to make that into a reftest.  We need a related class of problems fixed for mobile, so bug 602435 is likely relevant here.
FWIW, here's the content layer tree created by that test (will be the same for GL).

-671553536[2297ab0]:     BasicContainerLayer (0x36f8b60) [clip=(x=0, y=120, w=886, h=639)] [visible=< (x=0, y=120, w=886, h=639); >] [opaqueContent]
-671553536[2297ab0]:       BasicThebesLayer (0x36f6ea0) [clip=(x=0, y=0, w=0, h=0)] [transform=[ 1 0; 0 1; 0 120; ]]
-671553536[2297ab0]:       BasicColorLayer (0x3834b80) [clip=(x=0, y=120, w=886, h=639)] [transform=[ 1 0; 0 1; 0 120; ]] [visible=< (x=0, y=0, w=886, h=639); >] [opaqueContent] [noText] [noTextOverTransparent] [color=rgba(255, 255, 255, 1)]
-671553536[2297ab0]:       BasicContainerLayer (0x36f7270) [clip=(x=0, y=120, w=886, h=639)] [transform=[ 2 0; 0 2; -200 -120; ]] [visible=< (x=100, y=120, w=400, h=200); >]
-671553536[2297ab0]:         BasicCanvasLayer (0x36f73d0) [transform=[ 1 0; 0 1; 100 120; ]] [visible=< (x=0, y=0, w=100, h=100); >]
-671553536[2297ab0]:         BasicContainerLayer (0x36f7540) [transform=[ 2 0; 0 2; -300 -120; ]] [visible=< (x=200, y=120, w=200, h=100); >]
-671553536[2297ab0]:           BasicCanvasLayer (0x36f76a0) [transform=[ 1 0; 0 1; 300 120; ]] [visible=< (x=0, y=0, w=100, h=100); >]

My bet for the "ghost line" is on LayerManagerOGL::CreateFBOWithTexture creating a texture with wrapping GL_REPEAT (default) combined with something rounding a size up instead of down.
Actually, it isn't clear that that version of the test is suitable for a reftest; depends on the semantics we want for <canvas>.  A previous iteration though used divs to achieve the same effect, along with 1x1 transparent canvases to force the transformed divs into their own layers.
So, I think the main solution here for your texture testcase is using clamp rather than repeat. If you scale up something like this it's not incorrect for pixel coordinate 1.0 to partially sample a pixel outside of the texture bounds.
Assignee: tnikkel → nobody
This is still reproducible for me. Looks like it needs a new owner though?
Here's a fairly reduced testcase for the black squares type of artifact, only in this testcase it's white. It appears for me as soon as the viewport is at least 550px high.
Actually, the white box in the previous testcase seems to be a different issue than the black boxes in the original demo.
Here's a testcase for the black boxes. I had to add some JavaScript that periodically updates a div's transform so that it keeps its layer active.
Assignee: nobody → mstange
Status: NEW → ASSIGNED
This fixes the black boxes for me.

The problem was that nsDisplayTransform::IsOpaque didn't check the visible rect of mStoredList. In the case of attachment 493006 [details], the nsDisplayTransform's mVisibleRect was sized 128x128px, but mStoredList's mVisibleRect was empty. So mStoredList returned true for IsOpaque (it completely covered nothing), and the nsDisplayTransform item just returned true even though its visible rect wasn't covered at all.
Attachment #493074 - Flags: review?(roc)
Comment on attachment 493074 [details] [diff] [review]
correct nsDisplayTransform::IsOpaque

There's a subtlety here ... UntransformRect expands to the axis-aligned bounding rect. What you have here is OK since mStoredList.GetVisibleRect().Contains(untransformedVisible), then it certainly contains the actual (non-axis-aligned) untransformed rect. But you might want to mention it in a comment.
Attachment #493074 - Flags: review?(roc) → review+
Whiteboard: chromeexperiments
http://hg.mozilla.org/mozilla-central/rev/6aad676f008c
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Summary: Artifacts on depth-of-field chrome experiment → Black boxes on depth-of-field chrome experiment
Target Milestone: --- → mozilla2.0b8
Blocks: 615225
I've filed bug 615225 about the line artifacts.
Verified as fixed on:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0a1) Gecko/20111117 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0a2) Gecko/20111116 Firefox/10.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20100101 Firefox/9.0

http://mrdoob.com/projects/chromeexperiments/depth_of_field/ and the two test cases work fine on all Firefox versions.
Status: RESOLVED → VERIFIED
Whiteboard: chromeexperiments → chromeexperiments, [qa!]
You need to log in before you can comment on or make changes to this bug.