<br><br><div><span class="gmail_quote">On 3/14/06, <b class="gmail_sendername">IOhannes m zmoelnig</b> <<a href="mailto:zmoelnig@iem.at">zmoelnig@iem.at</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
ah i forgot: wouldn't it be even greater, if the objects wouldn't be so<br>restrictive with the size of the image?<br><br>proposal: add a header to the shm-segment where some basic information<br>(xsize,ysize,colorspace,...) is stored; this way, the [pix_share_read]
<br>would only need to know the shm_id (and this could even be made settable<br>at run-time)<br>[pix_share_write] would need to know the maximum size of the image to<br>allocate the memory.</blockquote><div><br>
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.<br>
<br>
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.<br>
</div><br></div>Of course, we still need some sort of WIndows equivalent as well.<br>