Closed
Bug 601894
Opened 14 years ago
Closed 14 years ago
Black boxes on depth-of-field chrome experiment
Categories
(Core :: Graphics, defect)
Tracking
()
VERIFIED
FIXED
mozilla2.0b8
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: sicking, Assigned: mstange)
References
()
Details
(Whiteboard: chromeexperiments, [qa!])
Attachments
(4 files)
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.
Reporter | ||
Comment 1•14 years ago
|
||
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: --- → ?
Assignee | ||
Comment 2•14 years ago
|
||
Reporter | ||
Comment 3•14 years ago
|
||
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 ;)
Comment 4•14 years ago
|
||
Interesting! They exist on windows hardware accelerated layers too.
Comment 5•14 years ago
|
||
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+
Comment 6•14 years ago
|
||
Happens on Windows without any hardware acceleration too.
Comment 7•14 years ago
|
||
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).
Comment 8•14 years ago
|
||
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
Comment 9•14 years ago
|
||
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?
Updated•14 years ago
|
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.
Comment 13•14 years ago
|
||
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.
Updated•14 years ago
|
Assignee: tnikkel → nobody
Reporter | ||
Comment 14•14 years ago
|
||
This is still reproducible for me. Looks like it needs a new owner though?
Assignee | ||
Comment 15•14 years ago
|
||
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.
Assignee | ||
Comment 16•14 years ago
|
||
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 | ||
Updated•14 years ago
|
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Assignee | ||
Comment 17•14 years ago
|
||
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+
Updated•14 years ago
|
Whiteboard: chromeexperiments
Assignee | ||
Comment 19•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/6aad676f008c
Status: ASSIGNED → RESOLVED
Closed: 14 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
Assignee | ||
Comment 20•14 years ago
|
||
I've filed bug 615225 about the line artifacts.
Comment 21•13 years ago
|
||
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.
Description
•