Multiple canvases and snapshot.txt

[kjetilly]

Currently snapshot.txt returns the result for only viewer key (the one specified as the get parameter), but I think we should have some possibility of sending a snapshot for all viewer keys in the exposedModel in one transaction, so one could open a new endpoint "snapshots.txt" which returns JSON-delimited basd64-encoded screenshots for each viewer, basically like this:

{
    viewer1: BASE64_ENCODED_PNG,
    viewer2: BASE64_ENCODED_PNG
 }

This should also be seen in conjunction with the auto-proxy branch, so perhaps the format should be:

{
    viewer1: {
         viewerElement: COPY_OF_MATRICES,
         rgb: BASE64_ENCODED_PNG,
         depth: BASE64_ENCODED_PNG
    },
    viewer2:  {
         viewerElement: COPY_OF_MATRICES,
         rgb: BASE64_ENCODED_PNG,
         depth: BASE64_ENCODED_PNG
    }
 }

When we switch over to binary transfer for images again, this could easily be solved by returning one huge image that is shared between the different parts (or use more advanced techniques).

[cdyk]

For the Apache module this should be quite straightforward. But wasn't base64-decoding surprisingly slow? Not that I have a brilliant scheme at hand that can send multiple images in one go.

[kjetilly]

I think for a long term solution we need a nice way of sending binary data to the JS-code. This is supported, refer to eg.

https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Sending_and_Receiving_Binary_Data

Though I am unsure of how portable this is. Conceptually one could at the very least do:

1. Send images binary encoded to client
2. Client decodes images (possibly using WebGL).

If we could do this with an ordinary request (ie. not using img.src) it would save a lot of work.

[kjetilly]

Also, this could help us in sending binary data:

https://github.com/dcodeIO/ProtoBuf.js