[GEM-dev] pix_buffer* & pix_write

[IOhannes m zmoelnig]

B. Bogart wrote:
> Hey all,
> 
> So I've been working a lot with the pix_buffer (depot) stuff and had a
> few ideas that would make using it even more useful:
> 
> * The ability to colour the buffer black, effectively clearing it
> without deallocating memory.

when we are there, why not set it to an arbitrary color? (i am not so a
big fan of named colors and prefer a numerical representation)

> 
> * The ability to load and save the images in a buffer, basically being
> able to take a snapshot of the system so that the same images that were
> in the buffers can be reloaded, restoring the original state.

> * It would be also nice to be able to save a particular frame rather
> than the whole buffer.

well this is something i wouldn't really care about.
if the whole buffer is saved, people have the choice to pick their
favourite frame with external software.

> 
> "load [filename]"
> to pix_buffer_read could load the [filename] into the slot already set
> by the pix_buffer_read index. "load [wildcard] 10" would load 10 images
> matching the wildcard pattern into 10 slots (reallocate if needed?)

have you ever tried to send [open <filename> <slot>( to [pix_buffer] ??

> 
> "save [filename]" to pix_buffer_write would save the image in the
> current slot to that filename. "save [filename] 10" could save images
> from the first 10 slots to filename with an id appended: "file0000",
> "file0001" etc..

storing the buffer to disk is on my todo-list.

there has been some discussion about how to interface the pix-buffer via
objects.
i still think that [pix_buffer_write] is the wrong place to store the
images to disk and i prefer [pix_buffer] (see the archives on more info).

basically [pix_buffer] is something like a [table], and
[pix_buffer_read] is like [tabread].

> 
> Oh and It would be amazing if you could put pix_write in a gemchain and
> have it only capture that gemlist in the buffer... or maybe the current
> pix_write should be called something like window_write since it does not
> actually save what is happening in the pix_ of a chain...

[pix_write] has been an error in the first place: reading the gl-buffer
 and writing them to disk should have always been separated into 2
objects. i recommend using [pix_snap]) and [pix_record] (though
[pix_record] is still a bit unstable on linux with certain codecs - any
help welcome :-))


mfg.asd.r
IOhannes