[GEM-dev] Growing pix_buffer?

[B. Bogart]

Great idea Chris!

Why did I not think of it...

.b.

chris clepper wrote:
> Ben
> 
> I don't see how setting a max number to grow to is any different than 
> allocating N number of frames to begin with.  GEM only grabs memory when 
> you put an image into a slot the first time or replace one with a 
> different size.
> 
> So you can do [pix_buffer biggie 10000] and only use 500 frames with no 
> penalty.
> 
> Chris
> 
> On Fri, Mar 12, 2010 at 5:12 PM, B. Bogart <ben at ekran.org 
> <mailto:ben at ekran.org>> wrote:
> 
>     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.
> 
>     .b.
> 
>     _______________________________________________
>     GEM-dev mailing list
>     GEM-dev at iem.at <mailto:GEM-dev at iem.at>
>     http://lists.puredata.info/listinfo/gem-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev