Does anyone have any suggestions about how one might go about making mcclim-freetype portable to other lisps? Seems like right now it's only usable for cmucl and sbcl.
I was thinking about either trying to translate the definer macros to acl ffi or, in the hopes of broader portability, to CFFI. But it seems like the defining sublanguage for CMUCL & SBCL is fairly different from CFFI.
CFFI-grovel seemed like another alternative.
Any suggestions?
thanks, R
rpgoldman@real-time.com writes:
Does anyone have any suggestions about how one might go about making mcclim-freetype portable to other lisps? Seems like right now it's only usable for cmucl and sbcl.
I was thinking about either trying to translate the definer macros to acl ffi or, in the hopes of broader portability, to CFFI. But it seems like the defining sublanguage for CMUCL & SBCL is fairly different from CFFI.
CFFI-grovel seemed like another alternative.
Any suggestions?
I'd suggest not bothering, and spending the time improving the gtkairo backend instead: you get antialiased graphics as well as antialiased text that way.
Cheers,
Christophe
Quoting Christophe Rhodes (csr21@cam.ac.uk):
I was thinking about either trying to translate the definer macros to acl ffi or, in the hopes of broader portability, to CFFI. But it seems like the defining sublanguage for CMUCL & SBCL is fairly different from CFFI.
Translating from alien to cffi is rather easy. It worked well for me with clim-cairo. It is mostly a matter of search&replace.
I'd suggest not bothering, and spending the time improving the gtkairo backend instead: you get antialiased graphics as well as antialiased text that way.
There might be code and ideas to steal from clim-freetype for gtkairo's benefit. (Warning, I have not actually investigated any of of following issues in detail, but here is my current impression:)
If I understand correctly, clim-freetype handles two problems: Selecting fonts through freetype. And actually drawing text.
Cairo has its own drawing functions, in two varieties: A "toy API" for text, which gtkairo is currently using. In addition, there is a much more nifty glyph-based API which probably has many advantages, although I am unclear about what those are.
If we wanted to do glyph-based drawing, clim-freetype might be a good inspiration for that code.
As for selecting fonts, cairo itself gives little control over that, but instead applications can look up fonts through either freetype or Windows APIs and use those with cairo.
It would be nice to translate the clim-freetype code for font selection from alien to cffi and adapt it for gtkairo.
gtkairo on Windows currently finds only sans-serif fonts. Not sure whether GTK+ on Windows supports freetype fonts or not, but probably either freetype or Windows functions will solve that bug. So it may turn out that a freetypification of gtkairo on Unix happens to fix the Windows problem, too.
Finally, if any of you have clim-freetype up and running on SBCL or CMUCL, can you do an experiment for me? Gtkairo's font drawing is currently relatively slow compared to CLX. What I do not know is how it compares to clim-freetype.
Could you perhaps benchmark CLX+Freetype for me? You don't need gtkairo for that. Just run clim-demodemo, select the drawing benchmark and run it with the text drawing option. The interesting bit would be to compare the resulting score between CLX with freetype and without.
Thanks, David
David Lichteblau david@lichteblau.com writes:
Finally, if any of you have clim-freetype up and running on SBCL or CMUCL, can you do an experiment for me? Gtkairo's font drawing is currently relatively slow compared to CLX. What I do not know is how it compares to clim-freetype.
Could you perhaps benchmark CLX+Freetype for me? You don't need gtkairo for that. Just run clim-demodemo, select the drawing benchmark and run it with the text drawing option. The interesting bit would be to compare the resulting score between CLX with freetype and without.
Haha. On my x86-64 workstation:
CLX: ~ 1000 +/- 30 operations/s CLX+Freetype ~ 50 +/- 2 operations/s
Cheers,
Christophe
"DL" == David Lichteblau david@lichteblau.com writes:
DL> Quoting Christophe Rhodes (csr21@cam.ac.uk): >> > I was thinking about either trying to translate the definer >> > macros to acl ffi or, in the hopes of broader portability, to >> > CFFI. But it seems like the defining sublanguage for CMUCL & >> > SBCL is fairly different from CFFI.
DL> Translating from alien to cffi is rather easy. It worked well DL> for me with clim-cairo. It is mostly a matter of DL> search&replace.
The reason I was worried about doing this was that the file I would search and replace in clearly states that it is auto-generated (sbcl groveler?) and should not be manually edited...
I should, of course, have mentioned this in my original email.
I take it from the above that I should just ignore that warning and dive in...
thanks, R
Quoting rpgoldman@real-time.com (rpgoldman@real-time.com):
The reason I was worried about doing this was that the file I would search and replace in clearly states that it is auto-generated (sbcl groveler?) and should not be manually edited...
;;; automatically generated, hand tweaked, do not regenerate.
I read that the other way around. :-)
d.
"DL" == David Lichteblau david@lichteblau.com writes:
DL> Quoting rpgoldman@real-time.com (rpgoldman@real-time.com): >> The reason I was worried about doing this was that the file I >> would search and replace in clearly states that it is >> auto-generated (sbcl groveler?) and should not be manually >> edited...
DL> ;;; automatically generated, hand tweaked, do not regenerate.
DL> I read that the other way around. :-)
Right you are. I probably lost track. Yesterday I went on a tour through CFFI-grovel, CFFI-Unix, SB-ALIEN, etc., and my head's spinning!
R
rpgoldman@real-time.com writes:
The reason I was worried about doing this was that the file I would search and replace in clearly states that it is auto-generated (sbcl groveler?)
No, the bindings were generated by Gilbert Baumann by some process I know no details of, but were initially cmucl-only and had nothing to do with the sbcl groveler.
and should not be manually edited...
David's already addressed this one ;-)
Cheers,
Christophe
In reply to myself, ...
Quoting David Lichteblau (david@lichteblau.com):
If I understand correctly, clim-freetype handles two problems: Selecting fonts through freetype. And actually drawing text.
FWIW, that wasn't entirely correct. Font selection would go through fontconfig, not freetype. clim-freetype doesn't seem to have anything to offer in this regard, it only does some run-shell-command thing to query fontconfig.
It would be nice to translate the clim-freetype code for font selection from alien to cffi and adapt it for gtkairo.
... so what gtkairo needs, especially for the Windows port, is actually Pango support for font selection.
d.
-
Christophe Rhodes -
David Lichteblau -
Robert P. Goldman -
rpgoldman＠real-time.com