Closed Bug 630835 Opened 15 years ago Closed 15 years ago

Transition paint wrong fragments at the end of transition for 1-2 seconds.

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: domain, Assigned: roc)

References

(
URL
)

Details

(Keywords: regression, testcase, Whiteboard: [hardblocker][has patch])

Attachments

(2 files, 1 obsolete file)

Testcase
1.80 KB, text/html
Details
v2
17.74 KB, patch
tnikkel
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10) Gecko/20100101 Firefox/4.0b10 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10) Gecko/20100101 Firefox/4.0b10 While playing around I find this bug. It happens ONLY if you have an transition inside of an object that is also in transition. At the and of all transition the Object show for 1-2 seconds a wrong "picture". (sorry my english) Reproducible: Always Steps to Reproduce: <!DOCTYPE HTML> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>Untitled Document</title> <style type="text/css"> body { font-size: 10px; } .test { position: absolute; top: -35em; right: 50em; display: inline-block; border: 3px solid #000; border-radius: 0.8em; padding: 1em; min-width: 30em; min-height: 30em; transform: rotate(45deg); -webkit-transform: rotate(45deg); -moz-transform: rotate(45deg); -o-transform: rotate(45deg); -webkit-transition: all 1s linear; -moz-transition: all 1s linear; -o-transition: all 1s linear; transition: all 1s linear; } .test:hover { top: -1em; transform: rotate(0deg); -webkit-transform: rotate(0deg); -moz-transform: rotate(0deg); -o-transform: rotate(0deg); } .test2 { display: inline-block; position: absolute; top: -17em; right: 40em; min-width: 20em; min-height: 20em; -webkit-transition: all 1s linear; -moz-transition: all 1s linear; -o-transition: all 1s linear; transition: all 1s linear; } .test2:hover { top: 0em; } .test2 div { background: red; min-height: 20em; -webkit-transition: all 1s linear; -moz-transition: all 1s linear; -o-transition: all 1s linear; transition: all 1s linear; transform: rotate(45deg); -webkit-transform: rotate(45deg); -moz-transform: rotate(45deg); -o-transform: rotate(45deg); } .test2 div:hover { transform: rotate(0deg); -webkit-transform: rotate(0deg); -moz-transform: rotate(0deg); -o-transform: rotate(0deg); } </style> </head> <body> <div class="test"> <input name="testinp" type="text"> </div> <div class="test2"> <div>test</div> </div> </body> </html> This happens on Mac (OSX 10.6) and Windows 7. On Windows the wrong painting is not so heavy as on mac. On google chrome and on safari it works right.
Component: General → Style System (CSS)
Product: Firefox → Core
QA Contact: general → style-system
Version: unspecified → Trunk
Attached file Testcase —
Hover the red square to see the problem.
I definitely see this on Mac. This is really bad.
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Component: Style System (CSS) → Graphics
Ever confirmed: true
Keywords: regression
QA Contact: style-system → thebes
The problem goes away if I disable hardware acceleration.
Tentatively calling this a hardblocker, because it indicates bugs in our container layers. The fact that it happens on both OS X and Windows is troubling, though...
Assignee: nobody → matt.woodrow+bugzilla
blocking2.0: ? → final+
Whiteboard: [hardblocker]
FWIW I can't reproduce on unaccelerated Linux and unaccelerated Windows (2000).
Something to do with antialiasing I guess. There's also some kind of black-edge artifact during the animation, on Windows. Bas might know about this.
There also a second problem if you look at my page: http://designgarden.cubernatic.com/home2/ you will see a div element with round corners that at the middle of the page. While loading you see the painting process. Thats really ugly. And funny it not happens with the elements on top of the page. Any ideas to this behavior?
This looks like a regression from component alpha landing, and appears to be a layout bug. In ContainerLayerOGL.cpp (line 178) we are detecting a fully opaque layer and not clearing the surface. With this testcase I get a visible rect (for the container) of: (gdb) p visibleRect $1 = { x = 889, y = -56, width = 252, height = 252, static kMaxSizedIntRect = { x = 0, y = 0, width = 2147483647, height = 2147483647, static kMaxSizedIntRect = <same as static member of an already seen type> } } Yet the red rectangle measures 202 pixels in both dimensions. This really doesn't sound like a fully opaque layer at all. Changing this code to clear the framebuffer partially fixes the testcase and leaves us with bug 622585 (though would break component alpha of course).
Frame tree dump of a nearby paint (not the exact same one as the above example). OGLLayerManager (0x1f8805e0) OGLContainerLayer (0x1f8af280) [visible=< (x=0, y=0, w=1440, h=765); >] [opaqueContent] [metrics={ viewport=(x=0, y=0, w=1440, h=765) viewportScroll=(x=0, y=0) displayport=(x=0, y=0, w=0, h=0) scrollId=0 }] OGLThebesLayer (0x1f8aff20) [visible=< (x=0, y=0, w=1440, h=65); >] [opaqueContent] [valid=< (x=0, y=0, w=1440, h=65); >] OGLContainerLayer (0x1aa87fa0) [clip=(x=0, y=65, w=1440, h=700)] [visible=< (x=0, y=65, w=1440, h=700); >] [opaqueContent] OGLThebesLayer (0x1aa88100) [transform=[ 1 0; 0 1; 0 65; ]] [visible=< (x=0, y=0, w=1440, h=700); >] [opaqueContent] [valid=< (x=0, y=0, w=1440, h=700); >] OGLContainerLayer (0x1b071d20) [clip=(x=0, y=65, w=1440, h=700)] [transform=[ 0.726814 0.686834; -0.686834 0.726814; 257.561 -645.319; ]] [visible=< (x=880, y=-50, w=261, h=252); >] [opaqueContent] OGLThebesLayer (0x1b071e80) [transform=[ 1 0; 0 1; 0 65; ]] [visible=< (x=881, y=-115, w=159, h=152); >] [valid=< (x=881, y=-115, w=159, h=152); >]
Assignee: matt.woodrow+bugzilla → nobody
QA Contact: thebes
Component: Graphics → Layout
QA Contact: layout
Assignee: nobody → roc
Hmm, I was seeing this, but now I'm not. Has this gone away by itself?
Ah no, I still see it with D3D10.
Attached patch fix (obsolete) — — Splinter Review
Everything's described in the patch.
Attachment #511529 - Flags: review?(tnikkel)
Whiteboard: [hardblocker] → [hardblocker][needs review]
Attached patch v2 — — Splinter Review
The previous patch caused lots of assertions because our computation of the chlid list bounds didn't take clipping into account.
Attachment #511529 - Attachment is obsolete: true
Attachment #511560 - Flags: review?(tnikkel)
Attachment #511529 - Flags: review?(tnikkel)
Whiteboard: [hardblocker][needs review] → [hardblocker][needs review][has patch]
This patch seems to cause REFTEST TEST-START | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/579808-1.html ++DOMWINDOW == 107 (0F705C58) [serial = 5738] [outer = 080A1D80] For application/x-test found plugin nptest.dll ###!!! ASSERTION: Wrong bounds: 'bounds == aChildren.GetBounds(aBuilder)', file e:/builds/moz2_slave/try-w32-dbg/build/layout/base/FrameLayerBuilder.cpp, line 1598
I cannot reproduce that assertion locally. Did you get it locally or on a tryserver build?
On tryserver (win32).
You tryservered v2 right? Do you have a link to the output still?
Pretty sure it was v2. http://tbpl.mozilla.org/?tree=MozillaTry&pusher=tnikkel@gmail.com&rev=3c06775de791 Note that there were other things in the push, so it is not certain to be yours (but seems likely).
Yeah. Can you try reproducing it locally?
It doesn't happen locally on my Linux machine with the patch in this bug.
How do you feel about marking the test as 0-1 assertions?
(In reply to comment #21) > How do you feel about marking the test as 0-1 assertions? I don't know yet, have to review the patch first.
I pushed some diagnostics to try, this should help sort it out. http://tbpl.mozilla.org/?tree=MozillaTry&rev=b79e0cf7cfc9
Looks like the output of that was Plugin 1460DEC0(ObjectFrame(embed)(1)) (6480,6480,0,0)(480,480,12000,12000) bounds=480,480,12000,12000 computed=0,0,0,0
That makes it look like the bounds returned 480,480,12000,12000 once and then later returned 6480,6480,0,0. So I was thinking about how this could happen. I guess it could happen when nsObjectFrame::BuildLayer calls mInstanceOwner->SetCurrentImage, changing the image. I still don't fully understand the sequence of events, but it's definitely a problem that nsDisplayPlugin can change its bounds during layer tree construction!
Is bug 634784 related to this, by any chance?
Keywords: regressionwindow-wanted
Whiteboard: [hardblocker][needs review][has patch] → [hardblocker][needs review tnikkel][has patch]
Comment on attachment 511560 [details] [diff] [review] v2 + nsRect bounds = state.GetChildrenBounds(); + NS_ASSERTION(bounds == aChildren.GetBounds(aBuilder), "Wrong bounds"); So this means that mBounds, the code for updating it, and GetChildrenBounds is basically debug only code then?
It's an optimization. aChildren.GetBounds makes us walk the child list again. I should add a comment to explain that.
Attachment #511560 - Flags: review?(tnikkel) → review+
Whiteboard: [hardblocker][needs review tnikkel][has patch] → [hardblocker][depends on 631388][has patch]
http://hg.mozilla.org/mozilla-central/rev/b8194445b364
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [hardblocker][depends on 631388][has patch] → [hardblocker][has patch]
Depends on: 636229
Verified on Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Status: RESOLVED → VERIFIED
The landing of this bug appears to have resulted in an issue with painting of video controls. Bug 640074.
Depends on: 654641
Depends on: 697647
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: