Hi Jack,
How would the annoyance of dynamic patching many pix_buffers be helped by needing many gemlists?
For the record, this is for storage, not for rendering. The gfx card will certainly not have enough memory to store what I'll need to, 1000s of high-res images...
.b.
Jack wrote:
Le vendredi 12 mars 2010 à 14:12 -0800, B. Bogart a écrit :
Hey all,
I'm use pix_buffers to store non-sequential images based on index.
I'd like to be able to grow a pix_buffer by 1 element at a time.
[add < would add a single slot to the end of the buffer. Its index would be calculated from the length of the buffer.
The object could initiated as a growing pix_buffer by using a 0 as the size argument.
There could be an upper limit of how many slots the buffer could grow to. Or a second argument could define the max size, but then it would need to send a signal when the buffer reached max, so maybe keeping tracking of the size on the PD side would work better...
Anyhow I'm just thinking aloud here.
The only alternative I can think of is using a bunch of pix_buffers, each holding a single image, that get dynamically created. That is bound to be a lot less efficient, and certainly uglier than a central storage area.
In this case, you can use [pix_texture] to store your 'image' instead of [pix_buffer]. ++
Jack
.b.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev