The algorithm to control the ellipsis in our canvas-based panels can be improved

[julienw]

The algorithm to control the ellipsis is implemented in https://github.com/firefox-devtools/profiler/blob/main/src/utils/text-measurement.js.

We can see in several profiles how it's not perfect: sometimes the text is cut too soon, sometimes too late. This is because we use an approximation in https://github.com/firefox-devtools/profiler/blob/bf0d12fe12d02855b9b8945c1a4d7f477d472aec/src/utils/text-measurement.js#L82-L92. We use this approximation because using the real measure in a loop is presumably too slow.

We could try various things:

• bisection instead of this dumb loop, possibly only a few measures would be necessary
• use a well positioned element for just the text, and let the browser do its thing

This measurement is used in all our canvas-based panels: marker chart, flame graph, stack chart.

This profile has a bunch of problems in the marker chart, some are too long (look at the Runnable line, or the label starting with PWebRenderBridge), some are too short (especially the network request here).

We should also probably avoid drawing a few characters only (there are even some examples where only the ellipsis is displayed, this is clearly useless).

┆Issue is synchronized with this Jira Task

[fqueze]

Another example profile where this was very visible recently: https://share.firefox.dev/3IEvkhl

[gregtatum]

We use this approximation because using the real measure in a loop is presumably too slow.

Yes, it's pretty slow to measure the text, so it's probably not feasible to measure the text in a loop. The browser will probably suffer from similar issues. It might be possible to improve the heuristics, but measuring in a tight loop is kind of a hard problem.

use a well positioned element for just the text, and let the browser do its thing

I'm skeptical this would be fast enough. The browser invokes all of the segmentation and font shaping code paths to make this happen, and doing this for all of the boxes in a graph probably would be to slow. That's just a guess though.

[gregtatum]

Or maybe schedule a debounced slower pass that renders it correctly after N seconds of the width not changing.

[julienw]

I'm skeptical this would be fast enough. The browser invokes all of the segmentation and font shaping code paths to make this happen, and doing this for all of the boxes in a graph probably would be to slow. That's just a guess though.

Maybe we can have a threshold to do it only for markers that are at least eg 10px. That should limit the amount of work.

[julienw]

This stackoverflow entry has a bisecting approach to this problem, like I suggested above: https://stackoverflow.com/a/68395616