Next chart formatting stuff

[davidlrichmond]

Useful perhaps to share a roadmap. I can see line of sight to a couple of additional quick axis formatting enhancements:

• Data Boundaries: Set bounds on the chart instead of forcing minimum to 0 as it does currently, or lock to minimum of data set. This could be a new optional tuple parameter (min, max) on the Scale class.
• Axis Description: Paint any arbitrary descriptive string on each axis ("Revenue", "Month"). This feature could also go as an optional parameter on Scale.

There's one IMO critical formatting feature I am not sure how to build myself:

• Legend Support: The example docs mention "automatic legend generation from color mappings" but this is not implemented that I could find. I haven't researched out how e.g. ggplot does this but there's questions around descriptive data labels (vs. lowercase/camelcase/underscored field names) and where to pass those labels, as well as graphical presentational aspects (size and positioning of legend, especially across screen sizes, border styles).

[rudi-q]

Hey @davidlrichmond 👋
Thanks for opening this.

Data Boundaries: The forced min=0 is annoying, and your (min, max) tuple idea makes sense. Should be a quick fix.
Axis Labels: Yeah, definitely needed. Pretty straightforward to add.
Legend Support: You're right to call this out. The docs mention automatic legend generation, but it's not implemented yet.
Legend is the trickiest one here. positioning, responsive behavior, mapping from field names to readable labels, etc. There are some design decisions to make around how the API should work.

I'm thinking tackle the first two quickly since they're straightforward, then figure out the legend approach. If you want to take a shot at either of the first two, I'm happy to review.

For the legend, I'd like to think through the API design a bit more first.

Appreciate you actually using this thing and calling out what's missing.
Thank you for your contributions so far and raising this 🙏 @davidlrichmond

[davidlrichmond]

Yes, sorry for any confusion, I meant to raise my hand to take on the data bounds and axis labels!

[rudi-q]

That's awesome! Really appreciate you jumping in on these.
Please feel free to go ahead 🙂

[davidlrichmond]

Hi! I've now opened a PR to resolve the data / axis bounds issue (and prettifying the scales!)

There was quite an expansion of scope on axis bounds. Along the way, though, I found two other issues that I decided to put out of scope for this axis bounds PR but are related to the Scale class.

1. I noticed that heat maps bypass GradientColorScale -- believe this is dead code in scale.dart, unfortunately. Instead, this chart type does color normalization directly in the painter. This duplicates code as the normalization logic exists in both Scale and the painter. It probably works, but it'd probably be better to unify into the new Scale implementation in the PR.

2. In searching the codebase for my refactor, I also noticed that the two export features have private _Scale classes duplicating the main scale coordinate mapping logic. There's an opportunity here to use the main implementation of Scale, which would have the happy effect of applying the Wilkinson algorithm to exported SVGs.

Neither of these issues are on the critical path for my use cases. I will continue to look at the axis labels, however.

[rudi-q]

Great catches on both of those - definitely worth addressing.

I'm planning to spend this week on tooltip improvements (#39), so if you're interested in tackling either of those issues, please feel free.

Would you want to open PRs for:

1. Heat map color scale unification
2. Export scale consolidation (+ Wilkinson for SVG exports)

[davidlrichmond]

Neither the heat map nor SVG export is on the critical path for my use cases right now, unfortunately -- but I will move ahead to the axis titles.

[rudi-q]

I see. No worries.

[davidlrichmond]

@rudi-q these 2 were pretty quick & simple, actually -- PRs coming soon for both refactors & I'm also going to take a stab at chopping up the 3.8k line AnimatedChartPainter.

[davidlrichmond]

@rudi-q on the SVG export.

Problem

The challenge is that any SVG renderer I can write duplicates positioning/layout calculations from AnimatedChartPainter.

DRY Refactor

The chart setup code would be relatively straightforward to extract:

• A new class ChartDataSetup would hold most parameters from class AnimatedChartPainter (except panXDomain, panYDomain, animationProgress).
• This class would implement core setup routines that are currently private methods on AnimatedChartPainter:
  • Gradient _applyAlphaToGradient(Gradient gradient, double alpha)
  • Scale _setupXScale(double width, bool hasBarGeometry)
  • Scale _setupYScale(double height, bool hasBarGeometry, YAxis axis)
  • ColorScale _setupColorScale()
  • SizeScale _setupSizeScale()
  • _LabelDimensions _calculateMaxLabelDimensions({ required Scale? xScale, required Scale? yScale, required Scale? y2Scale, required TextStyle style })

These methods all return well-defined components.

However, about 80%+ of the LOC here are _draw*() methods that return void. A lot of these methods (two-thirds? 85%?) have embedded geometry calculations that could go in a shared GeometryCalculator class returning data objects like:

• bar rectangles with positions/sizes/colo
• line point coordinates
• pie slice angles
• heat map cell layouts

Animation logic would need to stay in AnimatedChartPainter. GeometryCalculator would return full-size, unanimated geometry, and then the painter would apply animation delays/transforms before rendering.

I also think we can remove chart_widget.dart as part of any refactor here -- believe it's dead code.

Clear Benefits

Could enable multiple file format exports, chart features in widgets get automatic (probably) export, etc. Also, makes it way easier for AI tools to understand what's going on. Lmk what you think of the sketch above and happy to iterate.

Development Plan

IMO this is a great candidate task for full AI assist. But without regression tests in place for visual elements & rendering, I'm quite nervous about attempting it.

On my own project, I've used Alchemist for visual regression testing with platform-specific golden files. Local development PNGs can render text, while automated integration tests use black recntages where where text should be (this is expected behavior in headless CI environments without font access). The platform goldens serve as the source of truth for visual verification during local development with text rendering, while CI goldens can validate the same charts in the headless environment.

To set this up, use Alchemist's built-in golden testing with a unified management script that can selectively update platform-only, CI-only, or both sets of goldens, and automatically clean up failure artifacts. This lets contributors visually validate chart appearance locally while CI still catches pixel-level regressions without requiring font installation in the CI environment.

TLDR; what do I need from you? I think either:

1. Go ahead and take the whole refactor, prioritized based on your own sense of the export SVG feature's priority, or
2. Open a branch with some regression examples -- could start with the example showcase, I suppose -- and Alchemist testing. With your lean on what visual behavior is important to make sure gets preserved, I'm confident in guiding the AI assist through a refactor here.

What do you think?

[davidlrichmond]

@rudi-q FYI throwing a bit of spare time & tokens at an alchemist visual testing suite on #70 and will then throw the same at an AnimatedChartPainter refactor with the test suite as a fixed target.

[davidlrichmond]

Another path here could be to leave the visual regression tests in #70 NOT merged and just use them as a throwaway fixture for an AnimatedChartPainter refactor to be reviewed independently. One may reasonably feel that visual regression tests are more annoying than not based on dev style/philosophy. Let me know which way you'd prefer.