search

meltingice / CamanJS

Javascript HTML5 (Ca)nvas (Man)ipulation
http://camanjs.com
BSD 3-Clause "New" or "Revised" License
3.56k stars 406 forks source link

Some Performance Ideas #94

Closed henryfw closed 11 years ago

henryfw commented 11 years ago

Great work on CamanJS! I was playing around it on a 700px square png with "Caman.allowRevert = false" and the performance for some of the filters were taking awhile.

Edit: Part of why it was originally slow was because apparently FF is much slow than Chrome. On Chrome the speed is fine.

The parts from my diggings that can speed things up are:

1) Removing the calls to Util.clampRGB in Renderer.prototype.renderBlock made runs ~50% shorter. This removes the safety check, but with the default filters, I feel safe enough. If Util.clampRGB is removed in Renderer.prototype.renderKernel, then the sharpen filter will break. So Renderer.prototype.renderKernel should keep its.

2) Also in Renderer.prototype.renderBlock regarding "this.currentJob.processFn.call(pixel, pixel)", by using "this.currentJob.processFn(pixel)" without the "call" part, a ~20% speed increase is achieved, at least in FF. Naturally, this means that the "this" keyword in all the registered filters process callback will be broken, but since "pixel" is being passed as the only argument, it can still be referenced. A built-in filter that broke from this change that I found was "vignette" and "rectangularVignette". This is fixed but replacing "this" with "rgba" in their function bodies.

Doing these two changes made an original 12s call take 4.5s. Edit: Chrome takes 1.5s.

Again, CamanJS is awesome, and I'm only writing this because I think CamanJS is awesome. I hope this can be of help somehow.

Thanks, Henry

meltingice commented 11 years ago

Thanks for investigating and writing up your results!

  1. CamanJS originally did not bother with bounds checking and all was good, but then I quickly discovered that some browsers (namely Opera) follow the canvas spec a little more closely than others and basically freak out when a pixel color value is out of bounds. Thus, the value clamp. It sucks that it slows it down so much, but it is necessary to avoid unexpected results.
  2. This is a good find. Maintaining filter compatibility is something to keep in mind, but I'll do some testing and see if changing this is worth it for the next big release.