Improve flame graph rendering performance

[krsh732]

I'm not sure if I'm missing something more obvious, but these are the things being done in this PR:

• Reduce fillStyle and fillRect calls:
  • By using FastFillStyle.
  • By drawing the fill rectangle at an offset instead of drawing another white border.
• Removing the need to memoize style colors by storing them in a map ahead of time.
• Reduce render calls by pulling dragX/dragY out of chart viewport state.
• Replace getFittedText with an equivalent implementation that does less work.

Fixes #4451

Production | Profile of panning the flame graph in production
Deploy preview | Profile of panning the flame graph with PR changes

---

Some other things I tried:

1. Splitting the flame graph rendering into two passes (pass 1 draws rectangles and pushes visible texts to a list, pass 2 draws visible texts). It seemed to have made it ever so slightly more smoother, but numbers only showed average _drawCanvas time reducing from 4 ms to 3.8 ms.
2. Re-enabling requestAnimationFrame for FlameGraph canvas. This seems to make it slightly smoother, but not sure how to confirm. Profile
3. Disabling highlighting when panning. This also seems to make it slightly smoother but can't say for certain. Profile

[codecov]

Codecov Report

Base: 88.59% // Head: 88.64% // Increases project coverage by +0.04% 🎉

Coverage data is based on head (e558603) compared to base (b69a16c).
Patch coverage: 94.28% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4455      +/-   ##
==========================================
+ Coverage   88.59%   88.64%   +0.04%     
==========================================
  Files         284      284              
  Lines       25559    25528      -31     
  Branches     6877     6860      -17     
==========================================
- Hits        22644    22629      -15     
+ Misses       2708     2692      -16     
  Partials      207      207              

Impacted Files	Coverage Δ
src/utils/colors.js	95.45% <75.00%> (+13.93%)	⬆️
src/components/flame-graph/Canvas.js	91.93% <100.00%> (-0.13%)	⬇️
src/components/shared/chart/Viewport.js	96.08% <100.00%> (+0.05%)	⬆️
src/components/stack-chart/Canvas.js	94.41% <100.00%> (-0.04%)	⬇️
src/utils/text-measurement.js	100.00% <100.00%> (+6.66%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[julienw]

This looks pretty good to me, thanks a ton!

I only have a small comment about the result of the fitted text algorithm, tell me what you think.

In the future I'd like to use the real measureText, but with bisecting instead of iterating, which hopefully should be faster... but we'll have to profile to be sure :).

[krsh732]

In the future I'd like to use the real measureText, but with bisecting instead of iterating, which hopefully should be faster... but we'll have to profile to be sure :).

I was actually looking into improving this further locally. I tried bisection using ctx.measureText directly and the performance hit was real and noticeable for the profile in the linked issue. However, bisection does become more feasible if we use getTextWidth instead (ie. cache every intermediate step). Though the cache might very well be useless the moment maxWidths change (eg. window resize/node transforms?).

[julienw]

In the future I'd like to use the real measureText, but with bisecting instead of iterating, which hopefully should be faster... but we'll have to profile to be sure :).

I was actually looking into improving this further locally. I tried bisection using ctx.measureText directly and the performance hit was real and noticeable for the profile in the linked issue. However, bisection does become more feasible if we use getTextWidth instead (ie. cache every intermediate step). Though the cache might very well be useless the moment maxWidths change (eg. window resize/node transforms?).

Thanks for looking at it at least, we can discuss other solutions later. Maybe we can still find approximations that would work with the current not-very-good cases.