Re: PNG libraries on Mac OS (was Re: [XaraXtreme-dev] Problems with ranlib while compiling XaraLX)

[Alex Bligh <alex@xxxxxxxxxxx>]

Ben Fowler wrote:
> On 24/04/06, Ben Fowler <ben.the.mole@xxxxxxxxx> wrote:
> > [ snip ]
> >
> > This may not be the end of the story. Since wx makes use of PNG only as
> > backing for its wxBitmap class, there is an over-arching question of why
> > Camelot needs PNG at all. Whilst I haven't looked at every file, it would
> > seem plausible that the Kernel should use a Bitmap abstraction (such as
> > KernelBitmap) which could call through the Oil layer. If, for example,
> > that layer were to implement its Bitmap services simply by using wxBitmap,
> > there should be no need for Camelot to call any PNG routines, and no need
> > for any part of Camelot to include png.h.
> >
> > I would be tempted to rip out the OILBitmap classes (preserved in amber
> > perhaps, in case the bitmap code needs to be made pluggable) and replace
> > with wxBitmap. Of course, even if this were agreed, it is quite possible
> > that the time is not right, but I hope that my reasoning is clear.
>
> I meant to preface that by urging interested parties to study Chapter
> 10 of the Brooklyn Bridge book before deciding to go down the wxBitmap
> route. Just think, several days fiddling with the Makefiles, the code,
> and unit tests could save a few minutes reading the provided
> documentation.

Aaarrgghh - don't do this. OILBitmap has a different refcounting model
from wxBitmap, and is (somewhat bizarrely) a kernel base class. It also
has a whole host of functions wxBitmap doesn't. I've also found several
wxBitmap bugs. The main one is that you can't create arbitrary BPP
bitmaps in BPP different from your current screenmode (though you can
always generate full colour ones).

Camelot needs PNG because it is a supported file format! It's also
used in preview headers etc. If you really want to use wxWidgets
to serialize and unserialize PNG (which is I think what you are
advocating) then the answer is simply to convert the PNG in memory
to a wxImage (rather than wxBitmap) and serialize it. However, wxImage
is always 24bpp - if PNG's have lower bpp options (I can't remember)
you will lose palette options.

I don't really think there is a good reason to muck around with
program functionality just because there is a difficulty linking to
the library. If it's that difficult to find a "correct" version
of pnglib, then let's just distribute a known good version of
pnglib with the program. It looks to me vaguely like a BSD
license, but we can always stick it in a directory call
"pnglib" so it is clear it is not Xara copyright. Then platforms
with (ahem) interesting dependencies on pnglib (e.g. the Mac)
can use that.

Alex