Robert Goldman wrote:
OK. I stand corrected. Nevertheless, I argue that a freetype approach based on CFFI, which is portable over non-CMU-derived lisps as well as CMU-derived lisps is preferable, prima facie. Now, there may be some additional considerations that would make the CMU-derived-specific approach better, but I don't know of any. If you do, please let me know.
Note I'm not trying to brag about my code and denigrate others. All I did was tweak the CMU-derived-specific approach to backend to CFFI instead, a pretty minor change (and one that I did with virtually no understanding of the code.
To add some historical perspective to the issue:
The mcclim-freetype code was created by Gilbert Baumann. I did the initial conversion to SBCL. This involved more than just changing package names; in order to make it usable, the code had to be changed such that SBCL no longer warned about runtime calls to %SAP-ALIEN. Not only did it worn at compile time about this; it actually generated warnings at runtime initially too. Along the way, I added a few caches to speed up glyph rendering, which finally resulted in something I could bear to use daily in climacs and the listener.
Making the compiler happy wrt %SAP-ALIEN was not trivial, and if there's anything I would be worried about in the CFFI version, it's that somewhere one of those optimizations is not implemented. If it's usably fast, I guess everything is OK. Not having used CFFI, I don't know if SBCL will still warn about these as profusely as it does when using good ol' SB-ALIEN.