> Question: How "expensive" would measuring the text before doing > the real output in X11 be?
I do not know. It is likely that the correct answer will be "That depends" I guess. If the code is running on a local server, the round-trip will be a lot quicker than a transaction over the network... And I don't know to what extent things like glyph sizes or etc. may be cached either in the server, the client or even (in some places) by fltk itself... > Reasoning: In STR #2798 [1] there's a proposal to clip text before > drawing in X11, because of the problem with 16-bit coordinates > in X11 vs. 32-bit coordinates in FLTK. The proposed patch [2] is > incomplete (and not correct), but a correct clipping algorithm > would IMHO mean that we'd need to measure the text. The problem > is that text that would normally be outside the clipping range > could "wrap" into the display because X11 ignores the upper 16 > bits of the (FLTK) coordinate space. Note that this is not a > problem for Windows and OS X, since these are using 32-bit > coordinates anyway. > > Does anybody here know how "expensive" this would be in terms > of CPU usage and - probably *much* more important - X11 server > interactions? The measuring would have to be right before calling > > XUtf8DrawString(fl_display, fl_window, font_descriptor()->font, fl_gc, > x, y, c, n); I'd guess it could be pretty costly in the worst case - i.e. if you are on a remote display and need to make round trips over the network to the font server and so forth for each measurement... > in fl_font_x.cxx (isn't there another one for XFT?), so the font > for measuring the text would probably be set up already. That would be XftDrawString32() - or for the Cygwin/winxx X11 version, we use XftDrawString16() for compatibility with Windows 16-bit wchars. > Would this > introduce more X server messages, or would measuring be a local > operation? I don't think we cache the fonts locally, so I'd expect (but certainly do not know for sure) that this would involve a round trip. > Second question: What function should be used: fl_measure() or > fl_text_extents()? Would there be a performance difference to be > expected, or would it only be the small difference in the exact > layout? The latter could IMHO be ignored, I'd suggest to use the > faster method, because exactness wouldn't matter here, anyway. They also do slightly different things: fl_text_extents measures the "inked" area of the string, but assumes that the text is "ready to be rendered" when measured, whereas fl_measure does text wrapping and symbol expansion and so forth before measuring the string, so the results are not directly analogous. Note that fl_measure attempts to expand symbols and wrap text in exactly the same fashion as fl_draw would do when rendering a widget label, so it is probably the more appropriate method for this particular job. I assume what we are looking at here is how to stop widget labels from wrapping back onto the screen inappropriately? Though it may well be slower than fl_text_extents in the general case? Is there some brute force thing we can do, where we just say "that is Far Away from the screen, so I'll not bother even trying to draw it..."? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
