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
[email protected]
http://lists.puredata.info/listinfo/gem-dev
_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev
