On 3/14/06, IOhannes m zmoelnig <zmoelnig@iem.at> wrote:

ah i forgot: wouldn't it be even greater, if the objects wouldn't be so
restrictive with the size of the image?

proposal: add a header to the shm-segment where some basic information
(xsize,ysize,colorspace,...) is stored; this way, the [pix_share_read]
would only need to know the shm_id (and this could even be made settable
at run-time)
[pix_share_write] would need to know the maximum size of the image to
allocate the memory.

I thought about doing this but ran into the problem with letting pix_share_read know what size the image is after a change. I didn't think netsend or OSC would be suitable but maybe embedding the x,y,c size in the mapped memory would work.

I was thinking this would be a pretty specialized object anyway so the restrictions would not present a problem. The idea was to have different processes deal with capture, compression and display for installation type work.