[GEM-dev] Growing pix_buffer?

[B. Bogart]

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 at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
> 
> 
>