> On 07/17/12 11:06, Greg Ercolano wrote: > > On 07/17/12 07:33, darren legge wrote: > >> If I re-compile fltk to not use xft then it starts much quicker (4 seconds) > >> but utf8 characters do not show correctly. I thought xft was just > >> anti-aliasing > >> (which won't work with pcf fonts anyway). It seems xft is required for utf8 > >> to work though - is this true ? > > > > No, I don't think that's true; I've rendered utf8 stuff without xft, > > pretty sure. > > > > Many times I've seen my fltk apps displaying chinese/japanese > > in bitmapped fonts back in ye olde days (ie. in chunky, non-anti-aliased > > fonts). > > Here's some old screenshots from 2008 of Chinese and Japanese > rendered in what I think is non-xft contexts: > > http://seriss.com/people/erco/fltk/tmp/chinese-bad-character.jpg > > http://seriss.com/people/erco/fltk/tmp/input-japanese-with-fltk-1-3-x-10-27-2008.jpg > > There's a lot of messages on the newsgroup here from that period > covering how all that stuff works. Just sniff around for messages > from me/ian/matt/albrecht that include Fl::set_font()
Iâm running these on an arm target. The delay am seeing is in general with rendering windows and text. I used FLTK 1.1.7 with the latest Nano-X and Nxlib and found the performance to be the same as when I was using FLTK1.1.7 + Nano-X0.92 + Nxlib 0.45. This would eliminate Nano-X and Nxlib as being the problem area wouldnât it ? But with FLTK 1.3.0 and latest Nano-X, Nxlib delay seems to be considerable especially in windows where a sizeable amount of utf-8 text need to be rendered. I have disabled xft and donât have any problem displaying utf-8 characters except the delay issue am seeing. Would enabling Xft and using a ttf font make any difference ?
_______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
