Closed Bug 692968 Opened 8 years ago Closed 8 years ago

crash when doing javascript animation of 3D transform (css3-3d-transforms)

Categories

(Core :: Graphics, defect)

x86_64
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla10

People

(Reporter: jag.alves, Assigned: mattwoodrow)

References

Details

(Whiteboard: [inbound][qa!])

Attachments

(2 files, 1 obsolete file)

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
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
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
                        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.
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.
Attachment #566670 - Flags: review?(tnikkel) → review+
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.
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)
Depends on: 691864
Assignee: nobody → matt.woodrow
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+
Fixed review comments, carrying forward r=Bas
Attachment #566690 - Attachment is obsolete: true
Attachment #566703 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/6fa659437548
https://hg.mozilla.org/mozilla-central/rev/06c1b51c710f
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
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.