Montag, 25. Juli 2011

RLE - image encoding

As PNG was rather expensive for real-time image encoding, I implemented server-side RLE encoding. Compression for "typical" UIs yields about 120-200% the size of the equivalent png, however at a speed of about 300-1000mb/s on my 4 year old Notebook.

The data is sent to the client in binary format, and is decoded using JavaScript.
XHR1 for binary data transfer is also supported, but since XHR1 was never intended for binary-data-transfer it causes a performance hit.



IE9 was running on Win7 in Virtualbox (as all XHR1-Win7), however even under the same conditions, Opera/FireFox/Chrome were twice as fast.

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.


Mittwoch, 13. Juli 2011

Prebuilt demo release available

With GSoC2011 midterm evaluations approaching, I've created a runnable demo release, available at:
http://93.83.133.214/cacioweb/cacio-web-x86.tar.gz

To run your favourite app, (e.g. SwingSet2), simply:
  1. Untar the archive
  2. download recent jre/jdk7 bundle from jdk7.dev.java.net for 32-bit Linux
  3. copy libcacio-web.so into jre/lib/i386/ (or add it to the JAVA_LIBRARY_PATH)
  4. Start the server environment:
    java -cp cacio-web-runtime.jar:SwingSet2.jar net.java.openjdk.cacio.server.CacioServer
  5. Start the app in your browser: http://localhost:8080/AppStarter?cls=SwingSet2

Please keep in mind this is only a demo release, a lot of stuff hasn't been implemented or is disabled to avoid problems, For now only german keyboard layouts is (somewhat) properly supported, however for toying arround the input support for us keyboards should be sufficient.

Have Fun :)

Sonntag, 3. Juli 2011

Interesting & ugly stuff

The last few days I've been working on implementing copyArea acceleration, which is really a useful feature for faster scrolling. Instead of re-painting the whole scrolled area, only a small image of the "uncovered" are is sent to the browser - while the content already on screen is simply moved.
Supporting accelerated operations like this required quite a bit of tinkering with the code-base - accalerated operations require invalidated regions to be preserved before (which is why it wouldn't be wise to accelerate other primitives like fillRect too).
Long talk ... it still needs more work, because there are still artifacts. Other than that I am pleased with the performance results.

Now the ugly - keyboard events for now only work for basic characters on german keyboards.
Browsers are really broken in this regard. Sometimes the same keyCode is generated for different keys, sometimes keys can only differentiate by the order the keyPressed/Typed/Released events are generated.
All this is of course highly browser specific and without having an idea what keyboard layout is used actually, there isn't really a cure for the mess. Not so great idea to make a scripted document viewer the dominant runtime for distributed applications :/
Thanks a lot to the Joel Martin (Author of noVNC) who allows me to base my code on top of noVNC's input handling.