Azure canvas was turned on by default on all platforms for Firefox 18 (now on Aurora). And so we have finally removed Thebes canvas from Firefox 19 (current nightlies).
To recap, we previously had two implementations of canvas (not including WebGL canvases which are different). One using our older graphics library, Thebes, which is a thin wrapper over Cairo; and one using our new graphics library, Azure, which supports multiple backends (Cairo, Skia, Direct2D, and Quartz/CoreGraphics currently). To get to this stage we needed to get Azure canvas working properly on all platforms, which was finally finished off last cycle. Now that Azure canvas works properly, we can dump Thebes canvas, which removes a whole bunch of duplicated code, and thus duplicated effort in maintaining two implementations. Also, it means canvas always uses the new DOM bindings.
In the code, nsCanvasRenderingContext2D has gone and nsCanvasRenderingContext2DAzure has been renamed to mozilla::dom::CanvasRenderingContext2D. The various bits of XPIDL for getting a Thebes canvas rendering context has also gone.
If you are testing nightly, let us know if you spot any new bugs with canvas (including when printing, which uses (sometimes or always, I'm not sure) a canvas).
To recap, we previously had two implementations of canvas (not including WebGL canvases which are different). One using our older graphics library, Thebes, which is a thin wrapper over Cairo; and one using our new graphics library, Azure, which supports multiple backends (Cairo, Skia, Direct2D, and Quartz/CoreGraphics currently). To get to this stage we needed to get Azure canvas working properly on all platforms, which was finally finished off last cycle. Now that Azure canvas works properly, we can dump Thebes canvas, which removes a whole bunch of duplicated code, and thus duplicated effort in maintaining two implementations. Also, it means canvas always uses the new DOM bindings.
In the code, nsCanvasRenderingContext2D has gone and nsCanvasRenderingContext2DAzure has been renamed to mozilla::dom::CanvasRenderingContext2D. The various bits of XPIDL for getting a Thebes canvas rendering context has also gone.
If you are testing nightly, let us know if you spot any new bugs with canvas (including when printing, which uses (sometimes or always, I'm not sure) a canvas).
11 comments:
Amazing work Nick and team!
What's the new DOM bindings?
With HWA enabled, this demo is very slow :
http://soulwire.github.com/Coffee-Physics/
Choose Canvas as the rendering method.
With HWA disabled, the demo is smooth using canvas.
Thanks Manoj!
Anonymous: I'm not 100% up to speed in that area, but the DOM bindings are part of the magic that allow Javascript to interact with the DOM (which is coded in C++). The bindings are little bits of code for each DOM function/property to interact with JS. The new DOM bindings are a new attempt to speed up this part of Firefox, they are often called the Paris bindings, I don't know the specifics of how they differ from the old bindings though, sorry.
mayankleoboy1: thanks for the report. What platform are you on (Windows, mac, etc.)? And which version of Firefox are you using? If it is not a very recent nightly, could you try with that please? We have fixed a couple of bugs like this recently. If it is still slow with HWA, please let me know here or via bugzilla and I'll look into it.
iam using the latest nightly (20 oct).
Platform :32 bit nightly on win7 x64.
AMD HD5470M GPU with 12.6 catalyst drivers.
When i run the demo (with canvas as the rendering method) with HWA on, the demo uses 100% of my GPU , but get ~12 FPS.
With HWA off, the rendering is buttery smooth.
Hi mayankleoboy1, thanks for the details. I tried testing this, but I could not reproduce on my system, possibly it is due to driver issues - I have an Nvidia graphics card and that seems to be the only difference between our setups. It turns out we have had issues with this demo before, so I added a comment to bug 732471 (https://bugzilla.mozilla.org/show_bug.cgi?id=732471), you can follow any progress there and hopefully we'll get this fixed soon.
Nick, there was an AUA on Reddit yesterday, and a user reported the following:
I find that in my daily browsing there is barely any speed difference between Firefox and Chrome. Most comments on reddit seem to be anecdotal.
But! http://www.gibney.de/firefox_canvas_performance# if I use fillRect then I get about 1/10 of the frame rate in Firefox 16 compared to Chrome 22. (I'm using Ubuntu 12.10) For drawImage the frame rate is almost the same.
Can you ascertain what's going on here and whether this test case is representative of a broader set of slowdowns specific to Firefox.
Thanks,
Manoj
Nick, i have filed this bug :
https://bugzilla.mozilla.org/show_bug.cgi?id=809464
You might want to check it out.
pixman major release 0.28 released. Thought you might be interested.
http://lists.x.org/archives/xorg-announce/2012-November/002094.html
Manoj - thanks for that heads up, we saw the benchmark and are looking into perf there.
mayankleoboy1 - thanks for filing the bug, we've recently resolved some driver-caused bugs, but a proper fix is still in the works... I'm not sure what the plan is wrt Pixman, our version of Cairo is quite heavily patched so rebasing is non-trivial :-( I hope we can bring in the changes at some point though.
Post a Comment