599565 - ChromeExperiment lorenz-84 causes the browser to freeze

Status: RESOLVED INVALID

(Core :: Graphics: Canvas2D, defect)

Description

[sbologna]

User-Agent:       Mozilla/5.0 (Windows NT 6.0; rv:2.0b7pre) Gecko/20100924 Firefox/4.0b7pre
Build Identifier: Mozilla/5.0 (Windows NT 6.0; rv:2.0b7pre) Gecko/20100924 Firefox/4.0b7pre

This experiment uses pre3d to draw an object on the canvas.  Any attempt to interact with the canvas causes the browser to freeze for several seconds.

Reproducible: Always

Steps to Reproduce:
1. Go to the attached url
2. Launch the experiment
3. Attempt to interact with the object drawn on the canvas
Actual Results:  
The browser freezes for several seconds when the experiment is launched.  When the experiment begins, any attempt to interact with the object drawn in the canvas will cause the browser to freeze for several seconds again.

Expected Results:  
The object is meant to be rotated and moved around the canvas through drag and drop in real time.

I have tried running this with hardware acceleration on and off, and it made no difference

Comment 1

[Boris Zbarsky [:bzbarsky]]

Not seeing this on Mac, so presumably Windows-specific...

Comment 2

[sbologna]

Interesting you should say that, I just tried it using the win64 build Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre in Windows 7, and the experiement behaved even worse.  It took about five minutes to load, and the image didn't even get drawn properly.

Comment 3

[sbologna]

Attachment: Difference between Minefield-64 and chromium

The chromium screenshot is on the top, and the win64 minefield is on the bottom

Comment 4

[Scoobidiver (away)]

I can reproduce on Windows 7.
It happens also with Windows classic theme (no transparency).
CPU usage is about 50%.

For me, without HW acceleration, it is worse than with it.
So that means that HW acceleration does its job.
Could it be a Javascript bug and not a Graphics one ?

Comment 5

[[not reading bugmail]]

Attachment: lorenz84.js.txt - javascript file from this test

I suppose you could test how JM/TM handles this code on the testcase.

Comment 6

[David Mandelin [:dmandelin]]

OS-specific perf issues are rarely (although not never) due to JS. xperf shows this one is spending 93% of its time in d2d1.dll, and only 0.4% in mozjs.dll. Attachment forthcoming.

Comment 7

[David Mandelin [:dmandelin]]

Attachment: Windows 7 x86 profile

Comment 8

[Joe Drew (not getting mail)]

Bas, can you take a look at this and let me know whether it's something that should block? For now, let's say it does.

Comment 9

[Bas Schouten (:bas.schouten)]

(In reply to comment #8)
> Bas, can you take a look at this and let me know whether it's something that
> should block? For now, let's say it does.

So, this is due to the very large amount of complex strokes. In a hardware environment all these need to be tessellated. Making things worse there seem to be a lot of intersections, making it even more complicated! I don't think there's much we can do except try and detect this situation and fallback to software. In any case I don't have any ideas on how to make a big improvement here (some small improvements might be possible), this is absolutely the worst-case scenario for GPU acceleration.

I'd really like to hear if people have any good ideas, but blocking on this seems like it would put us in a difficult position.

Comment 10

[Bas Schouten (:bas.schouten)]

(In reply to comment #9)
> (In reply to comment #8)
> > Bas, can you take a look at this and let me know whether it's something that
> > should block? For now, let's say it does.
> 
> So, this is due to the very large amount of complex strokes. In a hardware
> environment all these need to be tessellated. Making things worse there seem to
> be a lot of intersections, making it even more complicated! I don't think
> there's much we can do except try and detect this situation and fallback to
> software.

Hrm, as the bug poster said, disabling hardware acceleration doesn't help here. I wouldn't be surprised if cairo draws this using tessellation as well, ending up in a similarly difficult situation. So the 'easy' software fallback solution isn't going to help at least!

Comment 11

[Lars Gunther]

I'm seeing this on Linux as well. (Fedora 12, Minefield 4.0b8pre on a Thinkpad z61p)

Comment 12

[Bas Schouten (:bas.schouten)]

Could someone on Mac confirm that this is much better on Mac? In that case it's mainly just Cairo and D2D both being very bad at this, and I'm not sure we can sensibly block betan on this. We need to develop a better rasterizer to fix this, which is not something I think we can do for FF 4.0,

Comment 13

[Boris Zbarsky [:bzbarsky]]

For me, on Mac, the rotations are instantaneous as far as I can tell.

Comment 14

[Joe Drew (not getting mail)]

This is probably just due to tesselation; fixing this isn't in scope for Firefox 4.