Image Draft Proposal

Dom Lachowicz <cinamod@hotmail.com>

Ok, so this is a starter for a new image infastructure. Comments are very much appreciated because this is very larval.

Image creation/handling already is done by platform-specific code (GR_UnixImage, GR_Win32Image, etc...) The problem is that while 90% of the code is shared, all of the interesting stuff is platform-specific, because RGBA buffers are very platform-specific. So what I want to do is provide a nice XP API which will wrap some (barely) p-specific problems.

What I suggest that will deal with is an ImageFactory class which is responsible with all of the nit-picky details related with assembling useful images. What I’m currently considering is an architecture kind-of like the following:

ImageFactory:

Is responsible for creating ImageSources. It will match the proper ImageLoader and ImageSerializer together for any given input type via an ImageSniffer

ImageSniffer:

For all intensive purposes, this is a recognizeContents and static_constructor replacement, so that images can be loaded via a plugin architecture. This is just an interface for specific subclasses to implement. Code for such sniffers can be taken right out of GdkPixbuf sources, for example. The sniffer can be asked to return an ImageLoader if it supports the content-type. May rely upon say IM or GdkPixbuf even... This interface and its subclasses will be XP, except if we choose to implement some platform-specific fancy library like GdkPixbuf or IM.

ImageLoader:

Reads PNG, JPG, whatever from disk and turns it into a platform-specific RGBA buffer. There will need to be platform-specific code here to handle proper creation of a platform-specific RGBA buffer (exactly how much remains to be seen).

ImageSerializer:

Takes a platform-specific RGBA buffer and turns it back into a specific format. Possible suggestions for this format include PNG and JPG, though there will be a “pluggable” list of such possible backends in an ideal world with one of them being the default (PNG). This class will require some platform-specific code.

ImageSource:

This class is a composite of an ImageLoader and an ImageSerializer. This is what we keep track of internally, reference count, live in the piece-table, etc..., and what will create our FG_Graphic images that we will later display. This class will be entirely XP.

FG_Graphic:

Somewhat similar to the present class. This will be produced from a specific ImageSource and will able to render to a specific GR_Graphics subclass through a generic API. This class will be entirely XP. It’ll keep track or rotation, scaled dimensions, etc... The most important method that it’ll expose is: render(GR_Graphics*)