Montag, 18. Juli 2011

Browser Benchmarks

Cacio-Web needs to send image-data as well as a command-stream to the browser which is quite tricky to do. It currently supports three different ways to transport data to the client/browser:
  • XHR, text transfer, image data encoded as Base64. (traffic+, server load+, client load-)
  • XHR2, binary transfer, encoded to Base64 on client-side. (traffic-, server load, client load+)
  • PngImage, command-stream encoded in image and extracted with getImageData. Should be fast, but causes browsers to crash and eat tons of memory - so not benchmarked for now. (traffic-, server load-, client load?)
Long talk, short story - here are the results for rendering a 33.6k png image over and over measuring browser-only performance. FireFox does quite well, when more time is spent executing javascript code (XHR2) Chrome catches up:

All in all, its amazing in how many ways things can be done - all of them beeing suboptimal. I have to render an image to a canvas (which can cause precission loss) to be able to access its pixel-values. Even if I have the binary data in a ArrayBuffer, I have to pass image-data using data-URIs - that sucks.


mcloud hat gesagt…

What kind of format are you using in the first 2 cases? /me thinks some kind of JPEG format might be appropriate (it wouldn't be supper high quality, but a high quality JPEG might be good enough and cheaper than PNG). Also, have you turned GZIP server side? Make sure the request also requests for it.

Linuxhippy hat gesagt…

I was using PNG for all cases, as JPEG is not really suitable for what I am doing.
GZIP is disabled for performance reasons (the benchmark focuses completly on client-side).

I've worked on my own image format using RLE compression, which yields good results. Server-side compression is extremly fast (~800mb/s on my laptop), and the format is simple enough to be decoded using javascript on the browser side.
With typical Swing applications, image-size is about 1.5-2.0x of the same image compressed as Png.