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.
Of course, we still need some sort of WIndows equivalent as well.