Sharing and Remoting

A common display server design challenge is to grant other programs access to parts of some output buffer or the contents of other windows. In the context of implementing screen sharing systems like VNC, they even need to inject limited input. Traditionally, this has been binary - you get the keys to the kingdom, or you get nothing at all.

There are two systems in place for this, the first is the encode frameserver as a designated binary that is started by the main arcan process with everything setup for sharing in advance. The second is the ability to explicitly push output segments to a pre-established connection.

The guarding principle is that the client doesn't know where the actual source material comes from, it can be provided buffers but it can't know if these buffers are the actual output to a particular display or not.

On the lower levels, this is treated similarly to the 'paste-into-client' side of a clipboard. The IPC container is the same as any normal window, it is just the direction of transfers and the synchronization/resize rules that have changed.

On the scripting side, this is managed by the define_feedtarget, define_recordtarget and define_nulltarget functions, where the normal one is define_recordtarget, and the others are optimized versions for specific purposes.

define_recordtarget is used something like this:

    rt = alloc_surface(640, 480);
    ch = define_recordtarget(rt, "protocol=vnc:port=6200", {vobj1, vobj2}, {aobj1},
             RENDERTARGET_NODETACH, RENDERTARGET_NOSCALE, -4,
             function(source, status)
             end);

The code reads as follows:

Allocate a buffer to use, and define that as the intermediate storage of our recordtarget. Populate that buffer with the contents of vobj1/vobj2 and keep them around in their current form and current dimensions, and update it every 4 frames based on the output display as a reference. This behaves similarly to define_rendertarget that is used for offscreen-rendering, the twist is that the destination buffer will be copied back to a CPU-side buffer and then synchronized with another process. In the form above, the encode_frameserver will be spawned.

It is also possible to specify the 'vid' handle of another connection to send to, and it would be treated internally like the creation of another window, just one that takes rather than gives.

The provided callback function works like other frameserver callbacks, and the client side can provide input events here, though it is up to the script to interpret and route based on what is best for the window management scheme in place. This set of features actually covers everything from streaming, recording, sharing, clipboard and drag and drop - with granular controls as to what is actually being shared.