Jump to content
mje

Get Text Rect VI Alternatives

Recommended Posts

I've identified a bottleneck in some of my more text-heavy picture based user interfaces as calls to Get Text Rect.vi. It's adding on the order of 100 - 1000 ms rendering time to my interface which otherwise does things in 10 - 100 ms depending on data density. To make matters worse it gets slower by a factor of 5x or so if a user-defined font is used (anything other than application/system/dialog). User-defined fonts are required to alter text size, so...yeah. S. L. O. W.

I'm platform locked so the GetCharABCWidths method springs out, but I'd have to dig a bit to figure out the data structures used in that call as I haven't really dealt with it before.

Has anyone tackled this before and can perhaps suggest alternatives?

Edited by mje

Share this post


Link to post
Share on other sites

Come to think about it, this is LabVIEW-- unicode/multi-byte isn't exactly a thing. So there's not a lot of printable characters. The interface uses the same font + size for the whole display, so when it's changed, run Get Text Rect.vi on all possible characters caching the results, incurring a relatively small cost, then the bounds for any string can easily be calculated without making calls to the underlying GDI layer. Should be fast. May need to have the caches keyed by style (bold, italic, none, or both).

Share this post


Link to post
Share on other sites

Oh I like that.  I too have done some image processing stuff and found that function to be quite slow.  One simple technique I wanted to try (but probably wouldn't help) would be to have a string control that isn't seen, and get the size of the text in it, after setting the text and information appropriately.  Not sure if several thread swaps using property nodes would be faster than the internal call to a LabVIEW function or not.  But caching the characters would definitely be faster.  I see a place where variant attributes could be used for sure.

Share this post


Link to post
Share on other sites

Given we're talking 7 or 8 bit characters depending on if you care about extended codes, and the first 32 codes aren't printable, I'd go with an array for direct indexing.

Share this post


Link to post
Share on other sites

So attached is my first attempt.  I did things a little different than you described.  For any one set of font settings I didn't generate the size of each printable character.  I only get the size of each character in the string and cached the result.  If that character for that set of settings was already generated it uses it.  At the moment it only supports Left to Right text, without offsets (unlike the normal method) but that could be added.  Also I included a test VI which after you run it a few times clearly generates text that is always faster than the built in method for a set of random strings.  If you open up the font range obviously it is less likely to have a cached value for your characters and will take longer.  Also my test runs the cached code twice, in the hopes I could see the difference when some text hasn't been cached but when you run it with 1000 random strings of random sizes it becomes noise quickly.

Get Text Rect Cached.zip

  • Like 1

Share this post


Link to post
Share on other sites

Just be careful with kerning. A "w" character followed by a "a", for example, might be narrower than the sum of the "w" and the "a" separately. I'm not sure how advanced the text printing functions are in LabVIEW, but true-type fonts are often kerned.

Share this post


Link to post
Share on other sites

Thanks for the advice.  On my system all of the string character sets I tried had the same result, summing their parts, as NI's method.

Share this post


Link to post
Share on other sites
8 hours ago, Thoric said:

Just be careful with kerning. A "w" character followed by a "a", for example, might be narrower than the sum of the "w" and the "a" separately. I'm not sure how advanced the text printing functions are in LabVIEW, but true-type fonts are often kerned.

Yep, I've confirmed that mucks things up good. Looks like I'll have to go hooovahh's route and cache the results of entire strings at a given font setting. Ugly, since the initial render will still be slow, but follow up renders will be quick.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.