Allow markers to provide a marker color.

[fqueze]

Adds an optional colorField field to marker schemas that specifies which marker data field contains a GraphColor value, allowing individual markers to render with different colors based on their data.

deploy preview

[codecov]

Codecov Report

❌ Patch coverage is 96.87500% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 85.82%. Comparing base (6b91dd5) to head (4df4352).
⚠️ Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
src/components/marker-chart/Canvas.tsx	96.55%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5607      +/-   ##
==========================================
+ Coverage   85.80%   85.82%   +0.02%     
==========================================
  Files         309      309              
  Lines       30381    30407      +26     
  Branches     8365     8370       +5     
==========================================
+ Hits        26068    26097      +29     
+ Misses       3892     3889       -3     
  Partials      421      421              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mstange]

Seems useful and the implementation looks fine.

The color contrast for hovered markers with the white text isn't great, but this can be improved in a follow-up.

I'm a bit concerned that we now have two sets of "accepted colors" along with "normal and highlighted" versions of each color. How bad would it be to reuse the category colors for these marker colors? The category colors have proven themselves to some degree in the stack chart and flame graph, for example I think they mostly have reasonable color contrast with the text that's on them, or at least if there were cases of really bad contrast we would probably have done something about it by now.

[fqueze]

Seems useful and the implementation looks fine.

Thanks!

The color contrast for hovered markers with the white text isn't great, but this can be improved in a follow-up.

Done in #5609.

I'm a bit concerned that we now have two sets of "accepted colors" along with "normal and highlighted" versions of each color. How bad would it be to reuse the category colors for these marker colors?

We already had these 2 sets of accepted colors when we merged support for marker tracks. That second set of colors solved two problems:

• the set of colors in src/utils/colors.ts provide 3 values: selectedFillStyle, unselectedFillStyle and selectedTextColor (+ gravity which is irrelevant for marker purpose). To draw the tracks, we need 3 colors: the fill color, the border color, and the dot color. In the marker chart, we also need 3 colors: selected and unselected fill colors and border color. For long interval markers, we could get rid of the border color and draw it in the selected fill color, and have a border less hovered markers (that would likely look cleaner). The border color is really needed for instant (diamond shape) markers that are close to each other, so we can distinguish the hovered marker from the surrounding markers.

• some colors used for the timeline would not look so great on charts. For example the orange unselected fill color would look worse than the current color on memory tracks. Maybe we would get used to it though.

Additionally, color.ts color consts for the teal and ink colors, but no associated color styles.

I would also prefer if we could merge these 2 sets of colors to have only one, but it would take significant effort to address the various edge cases.