On Sat, 5 Feb 2000, Andreas Beck wrote:
> > One library that does not use LibGGI and does not know about visuals.
> > It should dynamicly load readers/writers for different image formats,
> > and read images into/write imaghes from it's own simple structure
> > (basicly just width, height, format and a pointer to the data).
>
> Please not. Optionally yes, but don't load images into memory without need.
>
> A callback oriented approach would be much better. I've been bitten by that
> "oh, just put it in memory" concept too many times ...
On the flip side, MMAP (file) is your friend. Although never buffered...
(I've read the docs :)
... though just making an (access[block]) callback should do. After all,
the data could be stored in:
- A normal file (FILE* opers)
- a >2GB file (64bit file-ops in Linux; normal FILE* in NT; ???)
- a database record.... ie: BLOBs
- A subchunk within a larger file (embedded WWW for example)
- Another machine... (more later :)
There's others too.
> Adding a few simple "example-callbacks" that render into such a structure or
> a LibGGI visual can give the same ease of use if desired, but without
> straining my swap, if I don't want that.
Hah! Perfect :)
> > It should also be able to convert images between different formats.
>
> That could be done by chaining a load and a save call appropriately.
yep :)
Works in practice. Though I haven't used this in... uh... years.
Used it on a few -large- 3D-files... And use it now on databases.
> > The second library should be a simple glue-layer between the first
> > library an LibGGI. The reason to make two libraries that a generic
> > image loader/writer that is _not_ tied to any graphics/window system
> > is badly needed, and the first library will be just that.
>
> Yep.
All right already. Where's the code? :)
G'day, eh? :)
- Teunis
