> It may be a good idea to figure out why this is so slow. Apparently > *drawing* the text is reasonable, it is only the measurement that is > slow? That implies this can be fixed somehow. > > The fltk2.0 drawing code scrapped all uses of "measure 1 character", and > instead has a function to get the width of a block of UTF-8. It was not > hard to make the text editor use this only.
Agreed. The previous slowlyness came from measurement operations. The slowlyness appeared only when word wrapping was on. The text widget was slow (with wrapping on) because measurement is called many times, presumably to test all possible line ends until the first possible one is found. Conversely, with wrapping off, measurement and drawing are each called once for each line, and the widget drew very fast. This was corrected with an approach identical to what is done under WIN32: precompute single character widths, and do that efficiently, that is, only for those parts of the unicode range that are used. This algorithm, though, implies the loss of character kerning that is done by default by Mac OS (ironically, "FLTK" is a convenient example of text where kerning - between L and T - may occur). But ligatures between, say, arabic characters are kept. The current situation is that Fl_Text_Display is very usable on the Mac platform, so I believe it's ready for the 1.3 release. But, I agree a more pertinent question could be "Is it possible to drastically reduce the number of times fl_width() is called by Fl_Text_Display when word wrapping is on ?". Is fltk2.0 both quick and with kerning on the Mac platform ? Is the drawing code approach of fltk2 transposable to 1.4 ? _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
