586096 - Using Canvas at non-native size is very slow

Status: UNCONFIRMED

(Core :: General, defect)

Description

[Michael Dewey]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-us) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

If the height/width attributes of a <canvas> are not identical to the style.width/style.height settings, canvas rendering is extremely slow.  This happens both when the attributes are set by css/javascript as well as when width and height are changed to non-native size using ctrl+ or ctrl-

Many users of our site are complaining that our canvas drawing application is slow, and we are finding out that their browsers are not set to native size.  

Reproducible: Always

Steps to Reproduce:
1.Go to http://muro.deviantart.com
2.Set browser to non-native size by hitting ctrl+
3.Try drawing
4.Go to native size by pressing ctrl0
5.Try drawing some more and see how much faster it is

note: speed difference is more pronounced with larger browser window sizes
Actual Results:  
Much slower when not on native size

Expected Results:  
Should be pretty close to the same speed (webkit browsers are not effected by size)

Comment 1

[Jordan Gutterman]

It would be useful if you could try a Firefox 4 beta from firefox.com/beta, as there have been a lot of canvas performance improvements since 3.6.

Comment 2

[Michael Dewey]

Just tried:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b2) Gecko/20100720 Firefox/4.0b2

While there are overall speed improvements in canvas, it is still unbearably slow when the <canvas> is not at native resolution.

Comment 3

[Robert Longson [:longsonr]]

Does setting image-rendering help?

<canvas style="image-rendering: -moz-crisp-edges; "></canvas>

https://developer.mozilla.org/en/css/image-rendering

Comment 4

[Michael Dewey]

Yes, that helps the speed quite a lot.  The image quality degrades significantly, but the performance is much better.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Right.  Complex image scaling algorithms are... slow.

The ongoing 3d acceleration work will likely help here.  roc, is there a tracker to hang this off of?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, bug 580405 for GL for Mac/Linux. You can try setting MOZ_ACCELERATED=11 in the environment to enable it for yourself; there are many known problems, but the browser should work well enough for you to see if it helps with your canvas performance.

On Windows, D3D (and D2D) are enabled on trunk by default for some subset of systems already.

Check about:support. On any system with GL, D3D or D2D enabled, canvas scaling should be a non-issue.

Comment 7

[Wayne Mery (:wsmwk)]

Michael, all better now that bug 580405 is fixed?

Comment 8

[Wayne Mery (:wsmwk)]

Michael, bug 580405  was fixed in version 7.  Is it better for you since then? And see comment 6.


(In reply to Wayne Mery (:wsmwk) from comment #7)
> Michael, all better now that bug 580405 is fixed?

Michal wrote "What versions of Firefox support hardware acceleration on OSX?  Right now my app is specifying optimize-speed for image rendering, which more or less solves the issues (as much as performance issues can ever be "solved", you always want things faster).  The webkit browsers are significantly faster in the canvas-heavy stuff than my stock Firefox 10.0 build.  I was assuming that was because of the GPU thing."

Comment 9

[Eckard Berberich]

Wayne,
sorry, I can't test this issue since I'm very ignorant of HTML and have never used a canvas.