FWD » Core Development » User Interface

If the actual text metrics are not cached, the code falls back to using a scale factor scaleX computed from a sample text (even if the webscale is not present). This approach leads to inaccurate width calculations, especially when the current text has different characteristics (length, spaces, special characters, etc.) compared to the sample.

To move forward with this issue, I have a few questions in mind:

1. If the customer’s application includes a text-metrics.xml file, we should precompute the text metrics at client startup. While this ensures correct behavior once precomputation is complete, it introduces a significant startup delay: I’ve already tried this for a customer, and the delay was around 14 minutes.

The question is: should we cache metrics for all texts and fonts specified in the XML file? There are 27 fonts listed (actually 4 unique fonts with different specifications). Perhaps we could limit caching to MS Sans Serif in this case, since it accounts for 13 specifications. This would reduce the delay by half (around 7 minutes), but even that is far from ideal.

Another idea is to use multiple threads to parallelize metric computation at startup. Could this help reduce the delay to a more acceptable level?

What is the maximum admitted delay?

2. The goal of this task is to adjust or remove the scale-related code from GuiWebDriver.getTextWidth, as it relies on an incorrect assumption.
However, let's approach this step by step and observe the behavior when webscale is not used (i.e., set to 0), the text isn’t cached, and we call getTextWidth to obtain an accurate width. In this scenario, the code still falls into the scale section and applies a scaling factor: calculated based on the SAMPLE TEXT to the Swing metrics for the given text:

wRes = (int)Math.ceil(super.getTextWidth(text, fd) * scaleX);

3. Suppose we remove the scale-related code, could this negatively impact other scenarios? I’m not entirely sure whether this part of the code is still actively solving any relevant cases. It’s also quite old, so it’s understandable if you don’t recall the specifics. However, if you have any insights or ideas on what to include during the testing phase (when will be the case) to cover potential side effects, that would be helpful.

4. If we don’t have a text-metrics.xml file, the initial performance won’t be great, but as we navigate through the application, things will improve since metrics start being retrieved from the cache.

The question is: should we still keep the Swing metrics as a fallback? And if webscale is present, how should we handle this? We know that when webscale is absent, the web client’s computed width is generally more accurate than the Swing metrics.

If the customer’s application includes a text-metrics.xml file, we should precompute the text metrics at client startup. While this ensures correct behavior once precomputation is complete, it introduces a significant startup delay: I’ve already tried this for a customer, and the delay was around 14 minutes.

The experiment done was driven by the incorrect presumption that the screen has a lot of static labels. I don't think that was the case ... most of them were dynamically computed from a browse. Maybe it makes sense to rather check if this is actually required. I will drop the idea of sending text-metrics.xml on client side and precomute. I don't think we will ever get a good time with that.

3. Suppose we remove the scale-related code, could this negatively impact other scenarios? I’m not entirely sure whether this part of the code is still actively solving any relevant cases. It’s also quite old, so it’s understandable if you don’t recall the specifics. However, if you have any insights or ideas on what to include during the testing phase (when will be the case) to cover potential side effects, that would be helpful.

Eugenie is a watcher.
From my POV, this scaling was done exactly to avoid the enormous over-head to compute the width of every text.

The question is: should we still keep the Swing metrics as a fallback? And if webscale is present, how should we handle this? We know that when webscale is absent, the web client’s computed width is generally more accurate than the Swing metrics.

• please create a very small example in which the approximation fails. Maybe we are misunderstanding something or there is a bug. You can create an example in Java / JS just to prove that the algorithm there provides bad results.

PS: I also take into consideration that we may want to fine-tune the algorithm. Instead of sending one SAMPLE TEXT, maybe we can send a list and get more insight (based on length?). Maybe we can use a ratio for texts < 5 characters, < 10 characters, < 20 characters, etc.

Also, I think we came to the conclusion that white-space is a deal-breaker in this algorithm (#9842).

The labels from my previous note illustrate three scenarios:

1. When getTextWidth roughly matches the client’s calculated width: as seen with the Amount: label, where swing width × scale (0.8384 in this case) aligns closely with the actual width.
2. When getTextWidth overestimates the required width — for the Test test test: label, the method calculates 161 pixels, but the label actually requires only about 136 pixels. This causes the label to appear too far from the text input field.
3. When getTextWidth underestimates the required width — for the AVAVAVAVAV: label, it returns 158 pixels, but the label actually needs around 165 pixels to render properly. As a result, it appears too close to the fill-in input field.

I think the best kind of visualization would be by comparing JS to Swing (non-antialiased). What we do now is to compute a ratio and the goal is to show that that ratio is not consistent.

So, I think it is better to take the same word, compute the metric on JS and Swing then compute a ratio. That ratio should have a min/avg/max per text size.

I would expect to see a similar graphic as in #9985-9, but the Y axis is the ratio (Swing / JS). If the ratio method we have in FWD is right, then the graphics should look like a completely vertical line (min completely vertical, max completely vertical, avg completely vertical) and a single line (aka, the min should equal max and should equal avg).

• If the lines are not vertical, then different number of letters suggest different ratios
• If the lines are not identical (min=max=avg), then same number of letters, but different texts suggest different ratios.

I also noticed that changing RenderingHints between VALUE_TEXT_ANTIALIAS_ON and VALUE_TEXT_ANTIALIAS_OFF does not affect the width values returned by Swing metrics. I initially expected the width to increase when anti-aliasing is enabled, but it turns out this setting only influences how the text is visually rendered, not how its width is computed.

Paula, can you redo #9985-11, but also include texts till ~50 length? Some fill-ins and editors allow the input of names/addressed/etc. which tend to be longer than 10 characters.

Sure, do you want me to include only lowercase words, only uppercase or mixed ones?

Alex, let me know if you'd like the chart extended beyond 45 characters

Not really, I wanted to know if there is a trend in which longer texts tend to be more closer to the average than smaller texts ... it seems like so.

Paula, mind that FWD trunk has now a change for high dpi screens (#4135). The change is in trunk, but the task is in I.T. due to a small regression, quite unrelated. AFAIK, the changes are to the CSS to acknowledge high-dpi screen and improve text rendering (see #9800). Can you check out that changes and apply them to your tests? I wonder if the statistics change with that - aka anti-aliasing on high dpi screens is more accurate.

Eugenie, do you have other suggestions on how to improve the performance/correctness of GET-TEXT-WIDTH-PIXELS? In #7629 there was a partial letter being displayed because GET-TEXT-WIDTH-PIXELS returned a smaller size then the actually rendered text - resulting is a cut-off letter.

The problem was that the approximation of the JS text width had a smaller ratio and so it missed the actual size with 1/2 pixels.

Paula analyzed the approximation routine and it seems like texts <10 letters are prone to a big error margin. Some texts need 1.1 ratio while other need 1.3 ratio - same font, size and style!
The approximation for texts >10 letters have a smaller margin of 1.12-1.25, but this is considerable as well. If FWD appreciates that the avg. is 1.2, then some texts will be rendered with 0.08 ratio bigger and other with 0.05 ratio smaller.

I personally am quite satisfied with the approximation per se as it reduces a lot the communication between Java and JS, but #7629 seems to be quite pretentious. In that case, the fix was to bypass caching for that specific widget, but this is not a general fix.

Alex, I redid #9985-17, but is exactly the same with the one posted here.

I’ve been thinking about improving the way we handle text width measurements.

Right now we rely on Swing metrics plus a general scale factor, which is not very accurate.
We already have caching logic in place (if a width is obtained from the JS client, we mark it as "legacy" and reuse it for subsequent texts).

My proposal is to create a dedicated websocket for text measurement:

• The JS client would perform the actual measurement using the browser rendering context and return the exact widths.

• The dedicated connection avoids contention with the main application socket, so width requests won’t introduce visible loading or block other UI messages.

• With caching already implemented, only the first measurement for a given font/text would require a round trip, subsequent requests would be served from cache with no performance hit.

• This way we eliminate the unreliable scale factor approach and ensure no overestimate / underestimate will be present anymore.

But every improvement comes with a cost. As Alex mentioned, we might encounter a scenario where a window is initially rendered with the fallback implementation (like now), meaning labels could appear too far or too close to their text boxes because the metrics haven’t been computed yet. Once the improved measurements arrive, the layout would snap into place.

The question is: can this actually happen? If yes, how should we handle it, can we prevent it, or do we simply accept it as a trade-off? Also, would creating a dedicated socket solely for text measurements be a good approach to minimize this risk?

Any thoughts on this will be very appreciated.

Is there any further update since comment 23? I note the non-closed related items are also probably in need of an update too.

Unfortunately, no. A sketch solution was proposed, but other priorities took precedence, so we didn't move forward with it.

Paula, can you re-test this? #9842 was merged into trunk.

I'll retest #9933 and #10122.

#9933 isn't resolved.

#10122, neither.

Oh well 🤷 I saw this task related to #9842 so I said it's worth a shot.