cl-png is a long lived package that mostly works, but it contains a single flaw, it relies on the presence of a library and the competence of the implementation in getting to it.
It grabs the source and tries to build it. That’s one reason that I don’t much care for it. As much as I don’t mind C, I’d rather not force common lisp programmers to interact with that whole can of worms, and if that is its behavior in windows, then there may simply not be a suitable C compiler.
In the place of cl-png will slide pngload and zpng. zpng is a much more capable interface and pngload is actually remarkably fast. However, zpng and pngload are likely heavier than libpng, but, ultimately, the thing that takes time in this library is the rendering itself or pixel manipulation.
In the face of the immense demands of requiring a C compiler introduces, it’s not unreasonable to trade a little bit of performance somewhere non-critical for ease of distribution.
The switch was remarkably painless for pngload, but zpng had a few differences that proved a tad inconvenient for me in paritcular
- The format was different than the one I had chosen.
In cl-png the format used for images was a 3 dimensional array rather than a 1 dimensional array as zpng uses.
I use a 3 dimensional array because it maps more closely to how I think about images, - zpng has an accessor to obtain the 3 dimensional array, but it lacks a setter(which is probably all well and fair as the translation could be troublesome on the other end).
What would’ve made this easier for me would’ve been if zpng had provided a conversion function(maybe it did and I missed it), but writing it myself wasn’t terribly difficult in the end.
Leave a Reply
Only people in my network can comment.