>> So... it's fairly likely that the slowness comes from my ATSU font >> handling mods,
> Still, measuring a string was too slow, so I ended up calculating > character widths once, assuming fixed kerning, and storing all in a > fixed array. But that is not possible with UTF8 because there are so > many more characters. We will have to do some kind of hashing here, or > live with the slow implementation of ATSU, especially since I really > would love to reactivate the features mentioned above. It looks just so > much better. Yes - I saw the stored-widths stuff, but I couldn't figure any way to make that work with UTF8 either, so I've taken it out (for now, anyway) and and am using ATSU to measure the UTF8 (well, converted to UniChar actually) text for display. It does actually look pretty good - and it made implementing a right-to-left text widget really easy too. But, slower... > I do remember that "test/editor" was excruciatingly slow > on my G4, but introducing the width table fixed that issue. Yes, the editor is slooooow in my port, but I'm reluctant to move to a width table, as I can't see how to efficiently cover all the glyphs that might be used. Of course, for an "editor" widget, we *might* force a fixed-pitch font, then obviate the need to measure at all at run-time - but that's not really what people want from a generic Text_Display widget... Also - at a tangent - do we want to consider making the font ID code more than a uchar for a 1.1.x-utf8 port, now that many machines have more than 256 fonts installed? Cheers - and I really appreciate any pointer you can give, -- Ian _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
