680800 - canvas drawing images slow, and it stops the UI

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Notlost]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:9.0a1) Gecko/20110821 Firefox/9.0a1
Build ID: 20110821030758

Steps to reproduce:

http://alteredqualia.com/canvasmol/#Human_prion_protein
Enabled the Aspr link, and disabled aflt, which enables the image draw



Actual results:

Teh browser slowed to a crawl, and the UI became extremely laggy.


Expected results:

The molecule to draw properly, quickly. My config is able to handle MUCH more than this without a hiccup. (6000 images)

Comment 1

[Notlost]

should be asph

Comment 2

[Boris Zbarsky [:bzbarsky]]

This is pretty quick for me on Mac; sounds like a Windows-specific issue....

Comment 3

[Teodosia Pop]

I'm able to reproduce this issue with Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0 beta 2.

Graphics info from about:support
  
Adapter Description NVIDIA GeForce 210
Vendor ID 10de
Device ID0 a65
Adapter RAM 1024 
Adapter Driver snvd3dum nvwgf2um,nvwgf2um
Driver Version8.17.12.6658
Driver Date1-7-2011
Direct2D Enabled true
DirectWrite Enabled true (6.1.7601.17563)
ClearType Parameters ClearType parameters not found
WebGL RendererGoogle Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.686)
GPU Accelerated Windows 1/1 Direct3D 10

Comment 4

[Boris Zbarsky [:bzbarsky]]

Can you still reproduce if you disable hardware acceleration?

Comment 5

[Notlost]

Yes, but there is a large speedup. 
Firefox uses little CPU without accel?

Comment 6

[Notlost]

Odd. With accel it uses as much CPU as possible on one core.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Yes, but there is a large speedup. 

OK, sounds like something for the graphics folks to look into, then.

Comment 8

[Bas Schouten (:bas.schouten)]

This seems to happen both pre- and post-azure. It will have to be profiled.

Comment 9

[Bas Schouten (:bas.schouten)]

Profiling here shows the issue here is basically a very heavy usage of radial gradients. We spend a lot of time setting up radial gradient textures.

This is very unoptimized for the 'special case' radial gradient path in Azure. However if they're reusing the same radial gradient object we should be able to make this a lot faster by allowing the caching of the radial gradient texture in Azure, I'm looking into this.

Comment 10

[Bas Schouten (:bas.schouten)]

So, it looks like this is creating new radial gradients for each object, so there's no way we can actually cache the gradient texture or anything like that.

We could optimize for this test a little by caching some gradient stop collections in the Azure canvas backend if they're used a lot? It would certainly speed up this use-case but the heuristics would be a little tricky.

Comment 11

[David Vo [:auscompgeek]]

Does this also affect x86_64?

Comment 12

[David Vo [:auscompgeek]]

Oh, my bad. Reporter is using x64. Sorry for the bugspam guys.

Comment 13

[George Wright (:gw280) (needinfo me!)]

This is still an issue on nightly when using direct2d h/w accel.