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

[IOhannes m zmoelnig]

chris clepper wrote:
> 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.

ok, so i have implemented this now (and committed it)
additionally the new implementation  allows to "set" the attached
shm-segment during runtime via a "set" message, which takes the same
arguments as the object at creation time
e.g. [set 666 512 512 YUV(" will attach itself to the segment with the
key "666" and, if it is not yet made, it will be 512*512*2 bytes large.
any image which fits within this segment (e.g. a 320*240 RGBA image) can
be sent via this connection.
if the segment with the key "666" has already been made, the size
options will be ignored and those specified in the segment will be taken
instead. (if the sizes differ, the first object that refers (and thus
creates) the segment will win, so you need to be careful...)

oh, and i allowed symbolic id's (they are basically mapped to some
numeric value): i guess this could be of importance once we have a
similar mechanism for w32.

all in all, i am curious, whether it still compiles elsewhere.


mfg.asd.r
IOhannes