[GEM-dev] pix_share broken several ways

[IOhannes m zmoelnig]

chris clepper wrote:
> On 6/8/06, *IOhannes m zmoelnig* <zmoelnig at iem.at 
> <mailto:zmoelnig at iem.at>> wrote:
> 
> I have the current one working for up to one 1024x768 RGB buffer.  I'm 
> using it to have pix_snap write to shm and another instance of Pd record 
> the results as a Quicktime movie.  I can get about 30fps doing this, so 
> the objects are pretty useful.

well yes: the object IS very useful (for advanced uses)

> 
> 
> My thinking on the resizing is if the objects are 'smart' enough then 
> you could just put them into a render chain and any image that they get 
> feeds them.  I recall that Chris K and I got a little bit of this going 
> for vDSP/jMax, but that was a while ago.  I think our purpose was just 
> one shm region that set aside a large enough size for any video the user 
> was likely to throw at it. I believe the first N bytes were set aside 
> for the x, y and c size to let the receiver know how much of the region 
> to copy out and the dimensions to pass to the rest of the processes. 

actually it is almost like this.

> 
> Would this be a viable system?
> 
> - only one pix_share_write per ID (probably has to be like this anyway)

hmm, i don't see a real reason for this constraint (though again: i 
don't know where you would really want to use such feature)

> - default max size is a reasonable size (1024x768, 1280x1024,???)
> - arguments to the object can set the max size
> - any image that comes in under the max size set the x,y,c and copy the 
> frame into the shm buffer

actually this is how it works now: you define the default max size as 
argument(s) and any image that fits within this size can be sent via the 
shm buffer.

however, there is no "default" maxsize right now. probably SHMMAX would 
be a good starting point?

> - an image over max size would throw a message with a hint to manually 
> set the max

if we can resize the shm buffer while objects are still referring to it, 
this would be very cool.

> - some sort of flag or counter to determine when images are sent by 
> _write so _read doesn't copy out bad data

ah yes, the sync problem: i am not sure how to handle this efficiently 
(this is: not via netsend/netreceive)
can the shm-segment be locked?

> 
> This is kind of like sub texturing using 2D textures in a way.  It could 
> free end users from having to set anythign beyond the ID for common 
> video sizes (320x240, 640x480).  It is potentially wasteful if the 
> default is a lot bigger than the images used and it looks like OSX by 
> default is limited to 4MB of total shm, but manually setting the max 
> would help avoid this.

well, as long as it is shmmax<10MB i don't think that wastefullness is a 
big issue. (and if you are concerned you could always set a lower size 
explicitely via arguments)

by "total shm" you mean "the sum of all shm segments"? this would be bad!

> 
> Is this crazy talk?
> 

makes a lot of sense.

> 
> Like a Jack/Rewire method of passing video between apps?

i think this has been discussed at piksel 2 years ago.

shm is obviously the fastest, but you get huge penalties when using 
different apps that want the data aligned differently.


mfga.sdr
IOhannes