IOhannes m zmölnig wrote:
Update of /cvsroot/pd-gem/Gem/src/Pixes In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23076
Modified Files: pix_share_read.cpp pix_share_read.h pix_share_write.cpp pix_share_write.h Log Message: made it work on linux (even without crashes!); now you can also specify the 4th argument (color) as symbolic name like "RGBA" or "YUV":
of course this needs to be back-checked on osX. now that there are help-patches it should be fairly easy. chris: great object, btw.
mfg.hztr.a IOhannes
IOhannes m zmoelnig wrote:
IOhannes m zmölnig wrote:
of course this needs to be back-checked on osX. now that there are help-patches it should be fairly easy. chris: great object, btw.
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.
mfg.frew IOhannes
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.
chris clepper wrote:
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.
yep. using a networked connection for control data will give us a lot of race conditions which will almost always fail...
Of course, we still need some sort of WIndows equivalent as well.
afaik, there is nothing as elegant as shm on w32, however, there are memory mapped files (i found that via google: http://www.codeproject.com/threads/sharedmemipc.asp) which might work.
mfg.asd.r IOhannes
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
-
chris clepper -
IOhannes m zmoelnig