Closed
Bug 692968
Opened 13 years ago
Closed 13 years ago
crash when doing javascript animation of 3D transform (css3-3d-transforms)
Categories
(Core :: Graphics, defect)
Tracking
()
VERIFIED
FIXED
mozilla10
People
(Reporter: jag.alves, Assigned: mattwoodrow)
References
Details
(Whiteboard: [inbound][qa!])
Attachments
(2 files, 1 obsolete file)
907 bytes,
patch
|
tnikkel
:
review+
|
Details | Diff | Splinter Review |
1.69 KB,
patch
|
mattwoodrow
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111007 Firefox/10.0a1 Build ID: 20111007031227 Steps to reproduce: 1. go to http://www.w3.org/TR/css3-2d-transforms/#transform-property 2. type the following one-line script into the web console: window.setInterval("if(window.angle === undefined) window.angle = 0; document.getElementById('transform-property').nextSibling.nextSibling.nextSibling.style.MozTransform = 'perspective(600px) rotateY(' + window.angle + 'deg)'; ++window.angle;",100) Actual results: the table rotated for a while and then it crashed Expected results: it should keep rotating forever
Reporter | ||
Comment 1•13 years ago
|
||
Crash report: https://crash-stats.mozilla.com/report/index/bp-1c8c1300-8326-4560-bf95-76a5b2111007 Now the funny part: it doesn't happen in safe mode or with a clean profile. Disabling all add-ons didn't make a difference. During testing I also noticed that the rotated table is being clipped at (very roughly) 60~120 degrees, but with a clean profile it doesn't happen.
Component: Style System (CSS) → Graphics
QA Contact: style-system → thebes
Summary: css transform → crash when doing javascript animation of 3D transform (css3-3d-transforms)
Version: 10 Branch → Trunk
Assignee | ||
Comment 2•13 years ago
|
||
I can't reproduce this on mozilla-central, but I do get 'failed to create texture' assertions from ThebesLayerD3D10.cpp:416. aSize = {10485, 6401 }, and other crazy sizes that explain why we can't create textures. This is most likely because of bug 689416, and we no longer create intermediate surfaces in the container. Anyway, the bug still presumably exists, because we don't check the return value when we create textures in ContainerLayerOGL.cpp. We could also probably clip the created texture size to inverse transformed bounds of the current clip and stop this failing. I'm still looking into why the visible region is so big in the first place
Assignee | ||
Comment 3•13 years ago
|
||
nsDisplayTransform 1136E308(Table(table)(50)) (52820,-31 103,11576,130354)(0,0,0,0) Background 1136E308(Table(table)(50)) (4260,29082,78 360,9984)(0,0,0,0) opaque uniform TableBorderBackground 1136E308(Table(table)(50)) (-4 27490,-93734,480311,255616)(0,0,0,0) The offending element appears to be this TableBorderBackground.
Assignee | ||
Comment 4•13 years ago
|
||
I'm a little confused here. nsDisplayTransform::BuildLayer() calls FrameLayerBuilder::BuildContainerLayerFor. This sets the visible region of the container contents, which should be in untransformed coordinates, right? The visible region is determined by the bounds of the children, and in the case of TableBorderBackground, the visual overflow rect. Since this is the same frame, it is transformed, and the visual overflow rect is in transformed coordinate space. The frame width is only 78360, but the overflow rect width is 596308 because of the transformation. We then try allocate a ThebesLayer texture of this size, and fail.
Assignee | ||
Comment 5•13 years ago
|
||
Attachment #566670 -
Flags: review?(tnikkel)
Updated•13 years ago
|
Attachment #566670 -
Flags: review?(tnikkel) → review+
Reporter | ||
Comment 6•13 years ago
|
||
I must say that I can't reproduce the crash since at least monday's nightly. Maybe it was fixed in bug 689416 like you mentioned in comment #2 ? After landing I'll verify if the clipping differences are still present.
Assignee | ||
Comment 7•13 years ago
|
||
This fixes the crash/flickering but the text still dissapears at some angles. In these cases we're not creating the Text display items, so I believe this problem is the same as bug 691864
Attachment #566690 -
Flags: review?(bas.schouten)
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → matt.woodrow
Comment 8•13 years ago
|
||
Comment on attachment 566690 [details] [diff] [review] Check return values in ContainerLayerOGL Review of attachment 566690 [details] [diff] [review]: ----------------------------------------------------------------- Make sure you say ContainerLayerD3D10 in your commit message :) ::: gfx/layers/d3d10/ContainerLayerD3D10.cpp @@ +204,5 @@ > + HRESULT hr; > + hr = device()->CreateTexture2D(&desc, NULL, getter_AddRefs(renderTexture)); > + > + if (FAILED(hr)) { > + NS_WARNING("Failed to create new texture for ContainerLayerD3D10!"); Use LayerManagerD3D10::ReportFailure here. @@ +210,5 @@ > + } > + > + hr = device()->CreateRenderTargetView(renderTexture, NULL, getter_AddRefs(rtView)); > + > + if (FAILED(hr)) { Let's replace this by an NS_ASSERTION(SUCCEEDED(hr).
Attachment #566690 -
Flags: review?(bas.schouten) → review+
Assignee | ||
Comment 9•13 years ago
|
||
Fixed review comments, carrying forward r=Bas
Attachment #566690 -
Attachment is obsolete: true
Attachment #566703 -
Flags: review+
Assignee | ||
Comment 10•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/6fa659437548 https://hg.mozilla.org/integration/mozilla-inbound/rev/06c1b51c710f
Whiteboard: [inbound]
Comment 11•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/6fa659437548 https://hg.mozilla.org/mozilla-central/rev/06c1b51c710f
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
Comment 12•13 years ago
|
||
Verified as fixed on: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20100101 Firefox/9.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a2) Gecko/20111214 Firefox/10.0a2 Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111215 Firefox/11.0a1 The table kept rotating on all Fx builds. No crashes occured.
Status: RESOLVED → VERIFIED
Whiteboard: [inbound] → [inbound][qa!]
You need to log in
before you can comment on or make changes to this bug.
Description
•