On 24 Jan 2010, at 10:42, Matthias Melcher wrote: > On 23.01.2010, at 19:50, Evan Laforge wrote: > >> Hi, here are some regressions with fltk 1.3. I reduced the file >> demonstrating the problem as much as possible, it's still 150 lines >> but should be clear. I haven't dug into the fltk side yet to see >> where the problem lies, but I won't have time for the next few >> days so >> I thought I'd throw this out first. > > Well, OS X always had the problem that calculating text width is > very slow. Under FLTK 1.1, I use a lookup table and a few tricks to > accelerate text calculation and it worked very well. Now with UTF8, > we need to support a huge number of characters and have to resort > back to the slow OS based functions. > > I will see if we can find a good solution for this, maybe using > some kind of caching.
I think this is (possibly) exacerbated on the 1.3 tree by my use of Transient Font Matching. This is Very Useful if you are rendering utf8 text, since it makes choosing a "suitable" font much easier - the font engine just "magically" fills in any character glyphs that are missing in the currently selected font, by searching the other fonts it has available to see if the required glyphs are present... But this can be quite slow (as I'm sure you can imagine!) One of the other problems (rather than simply speed) with the Apple implementation of Transient Font Matching appears (at least, in my random tests) to be this: Although it returns a glyph from a different font from that which you selected, the metrics returned for the glyphs still seem (often) the be based on the selected font, so the string dimensions may be miscomputed by the fltk measurement code. Which I think then contributes to some (though I do not think *all*) of the layout issue that Evan reports. I still think Transient Font Matching is a Good Idea, which is why I turned it on, but if others disagree, well, I made it easy to turn it off. See the file fl_font_mac.cxx, around line 141, we have: # define ENABLE_TRANSIENT_FONTS 1 # ifdef ENABLE_TRANSIENT_FONTS // Now, by way of experiment, try enabling Transient Font Matching, this will // cause ATSU to find a suitable font to render any chars the current font can't do... ATSUSetTransientFontMatching (layout, true); # endif So... As I read it, after Manolo's patches were merged, this is probably not active for the 64-bit builds, but is active for 32-bit builds, either Quartz or Cocoa. It would be interesting to hear what Evan finds running his test for: - 64-bit builds - 32-bit builds with ENABLE_TRANSIENT_FONTS undef'd in fl_font_mac.cxx In the broader scope, the recent winXX versions (Vista, Win7) appear to automatically do Transient Font Matching without any special setup at all. WinXP and earlier do not, so far as I can tell, and it is not clear if it is even possible on those platforms. On linux platforms, we can leverage XFT to get better glyph coverage than we do at present (though it is not trivial) and there are patches from Timothy Lee that enable chunks of that functionality that we need to seriously consider merging in. A more complete linux implementation would probably mean resorting to PanGo or ICU however, and I don't want to go there if we can avoid it! -- Ian _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
