Am On 08.05.2012 14:38, schrieb MacArthur, Ian (SELEX GALILEO, UK) wrote: > >> 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...
Yeah, that was why I was asking, and I'm aware that a round-trip to a remote server would take relatively long. I'm mostly interested in a "worst case" scenario, so that this measurement wouldn't make FLTK feel unusable in a remote server setup. So, if measuring would always be a local issue, then it would maybe be okay, but if server roundtrips were involved, then ... well, this would probably exclude this approach. >> 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... That was basically the question: does it need server round-trips, or is it local? >> 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. Ah, okay, then this other place in the code is in fl_font_xft.cxx. >> 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. That would be bad :-( >> 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. Hmm, I was aware of the slight differences in measurement, but not that they also differ in symbol expansion and text wrapping. I should have known though.. > 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'd say, that depends. I may be wrong, but I assume that "here" (in fl_font_x[ft].cxx) the text would already be broken up in pieces that could be rendered directly (with one of the X*DrawString functions) so that in this context fl_text_extents() could also be appropriate (and more exact). > I assume what we are looking at here is how to stop widget labels from > wrapping back onto the screen inappropriately? I think that was the STR poster's intention, but in the context given it could be any string in any *draw* function. > Though it may well be slower than fl_text_extents in the general case? Okay, so if we'd look directly at the label on a higher level draw function, then wrapping and symbol expansion would be needed, and fl_measure() would be appropriate, but "here" in the given context we're probably looking at broken-up strings ready to be rendered, and then fl_text_extents() would be the better function? > 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..."? That's probably what the given patch tries to do, and what we could end up if measuring the text would be too expensive or too complicated. My concern is with an example like this: const char *s = "This is a very long string [...add many bytes...]"; fl_draw(s,strlen(s),32500,100); The given patch would only check x/y and say it's okay to draw the string, but this would probably be more than 300 px wide and hence overflow the short range. ... But then, hmm, ... thinking about it ... , would it matter? This would be far in the *negative* coordinate area, and then it would probably be clipped correctly by X11? Is there only a problem, if this string would be drawn with, for instance "fl_draw(s,strlen(s),65400,100);" ? Then it could really be clipped (ignored) by the draw function, because it is far outside the short range. Maybe there are other examples, or is it really *that* simple to check only the x/y coordinates for "far away", and clip the entire text then? What if we have coordinate transformations with a transformation matrix? Are these basic text drawing functions located after the transformation, and therefore in device coordinate space, or do we have to do coordinate transformations (or at least take them into account, if they would be done "later" by the X11 drawing functions)? Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
