[GEM-dev] Re: [GEM-cvs] pix_share_*

[chris clepper]

On 3/14/06, IOhannes m zmoelnig <zmoelnig at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060314/0be10f48/attachment.htm>