Re: [Plib-devel] Exposed bitmap loaders in SSG?

[steve <sjb...@ai...>]

Jan Reucker wrote:
> Am Sat, 6 Jan 2007 20:54:16 +0100 schrieb Jan Reucker <slo...@gm...>:
> 
> Some additional thoughts:
> 
>> - define a unified API for the raw loaders, maybe using
>>   some kind of piImage object to store the raw image data and some
>>   additional information (width, height, pixel format)
> 
> This approach would be similar to ssgTexture. There's one class
> for all texture formats. The ctor can be called with any file
> type and hands it over to a non-class loader mechanism, which in
> turn calls one of many non-class loaders to get the raw pixel
> data and some additional info.

Yeah - I like this.

> On the other hand we could define a piImage base class and a set
> of derived classes, one for each file type. Then we'd need a
> non-class loader function that uses one of the derived classes
> to load the image and then returns a piImage* base pointer to the
> caller. To the user, this is similar to ssgLoad().

I've come to dislike this approach.  One of the nice things about
OSS software is that you can replace the library without rewriting
the application that uses it.

If PLIB added a new image format (say 'TIFF') sometime in the
future - then only applications that were compiled with 'piImageTIFF'
would be able to load TIFF images.  That's unnecessarily
restrictive.

If on the other hand we had a classless 'factory' function that
you passed the filename into - and got a class piImage back (
which might in fact be a derived class of piImage) - then the
issue of which image formats are supported becomes largely
irrelevent to the application.  All it does is pass in the
filename (which the end user may have picked from a file picker
dialog box) - and it gets back a standard structure with stuff
like the actual pixel data, the height, width, bytes-per-pixel,
etc.

Then, the application doesn't have to care what image formats
are supported.   All the ones we support 'just work' without
the application having to know.

We certainly want a way for the application to ASK what formats
we support - or whether we support a specific format - but we
certainly don't want to have a specific class for each image
format that is exposed to the application (although internally
to the library, that makes a lot of sense).