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