[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

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

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

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.