User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 Build ID: 20150815030208 Steps to reproduce: with fresh profile, go to http://ctho.org/toys/JSraytracer/raytrace.html click onm start. Note the total time for the 19200 steps to complete Actual results: Nightly is much slower than chrome. Chrome : 10 seconds Nightly : 160 seconds Expected results: faster than chrome.

e1s off/on doesnt make much of a difference. Also, the benchmark slows over time. So that initially its quite fast. But around the 5000 mark, it begins to slow, such that each 100 point increase is slower than the last. FWIW, Edge browser show the same behavior. Chrome is far better.

It is much faster if HWA was disabled (i.e., layers.acceleration.disabled = true). Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 ID:20150815030208 The slowness is regression in Firefox7. Regression Window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c65f1fb0449d&tochange=46c3d095bc75 Regressed by: Bug 651858

Anybody who would like to get a profile on this? This is likely just a way they're drawing to the canvas that doesn't sit well with D2D (which would be why edge has the same issue).

Gecko profiler(Nightly43.0a1 without e10s): http://people.mozilla.org/~bgirard/cleopatra/#report=e93df8a4c5958ec5466a924c8a38f4fa94da7a90 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 ID:20150817030209

(In reply to Alice0775 White from comment #4) > Gecko profiler(Nightly43.0a1 without e10s): > http://people.mozilla.org/~bgirard/cleopatra/ > #report=e93df8a4c5958ec5466a924c8a38f4fa94da7a90 > > > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 > ID:20150817030209 Thanks a lot! So this is caused by a bug in the application... During the pixel rasterization loop this application does a useless moveTo() and Stroke() for no apparent reason. The moveTo here causes us to expand the currently active path, the stroke causes us to finalize the path and try to draw it (even though we're not actually drawing anything since there's no lineTo instructions in it). The subsequent moveTo will copy the old path in its entirety in order to append another moveTo to it (since there's never a newPath instruction). Chrome probably happens to optimize this away, this would require some work for us which I don't think is very useful since this is really just a bug in the application. I've locally removed the pointless moveTo and Stroke from raytracer.js (line 141 and line 144 respectively) and it completes in times similar to Chrome. The author should probably fix this testcase. Let me know if there's any other questions.

Nah, you explained it fine. I've contacted the author of the page. Hopefully he will change the offending code. I will update here if he does so.