Closed Bug 680800 Opened 13 years ago Closed 3 years ago

canvas drawing images slow, and it stops the UI


(Core :: Graphics, defect)

Windows 7
Not set





(Reporter: rockachu2, Assigned: bas.schouten)


(Whiteboard: [testday-20110826])

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:
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)
should be asph
Product: Firefox → Core
QA Contact: general → general
Version: 9 Branch → Trunk
This is pretty quick for me on Mac; sounds like a Windows-specific issue....
Component: General → Graphics
QA Contact: general → thebes
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
GPU Accelerated Windows 1/1 Direct3D 10
Ever confirmed: true
Whiteboard: [testday-20110826]
Can you still reproduce if you disable hardware acceleration?
Yes, but there is a large speedup. 
Firefox uses little CPU without accel?
Odd. With accel it uses as much CPU as possible on one core.
> Yes, but there is a large speedup. 

OK, sounds like something for the graphics folks to look into, then.
This seems to happen both pre- and post-azure. It will have to be profiled.
Assignee: nobody → 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.
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.
Does this also affect x86_64?
Oh, my bad. Reporter is using x64. Sorry for the bugspam guys.
Hardware: x86 → All
This is still an issue on nightly when using direct2d h/w accel.
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.