What you'll learn
Draw efficient custom graphics with Canvas and CustomPainter while preserving hit testing, repaint discipline, and semantics. The lesson turns the APIs into a repeatable engineering workflow instead of a collection of isolated snippets.
By the end of this lesson, you'll be able to:
- Apply Canvas in a production-shaped Flutter feature
- Apply Paint and paths in a production-shaped Flutter feature
- Apply CustomPainter in a production-shaped Flutter feature
- Apply Repaint contracts in a production-shaped Flutter feature
Core mental model
Connect each API to the decision it supports. Flutter code stays maintainable when state, ownership, lifecycle, and platform boundaries are explicit.
| Concept | What it means | Decision rule |
|---|---|---|
| Canvas | An imperative drawing surface within a widget's paint phase | Use when normal widgets cannot express the graphic efficiently |
| shouldRepaint | A contract that decides whether a new delegate changes pixels | Compare every field that affects drawing |
| Semantic alternative | Equivalent meaning exposed without relying on pixels | Pair custom charts with a concise label or data table |
Professional workflow
Work in small vertical slices and keep behavior observable from the first iteration.
- Define the efficient accessible chart boundary: user goal, inputs, visible states, ownership, and expected failures.
- Build the smallest working vertical slice with typed data and explicit dependencies.
- Represent loading, empty, success, and failure behavior where the feature can encounter them.
- Verify logic away from the UI, then exercise the rendered behavior at its public boundary.
- Inspect lifecycle, accessibility, performance, security, and platform behavior before widening the feature.
- Refactor only after behavior is protected by repeatable evidence.
Protect the frame
Guided Flutter lab
Build a focused efficient accessible chart slice
This compact example keeps the important ownership and data-flow decisions visible so the behavior is easy to extend and test.
class ProgressRingPainter extends CustomPainter {
const ProgressRingPainter(this.value);
final double value;
@override
void paint(Canvas canvas, Size size) {
final stroke = Paint()
..color = Colors.lightBlue
..style = PaintingStyle.stroke
..strokeWidth = 10
..strokeCap = StrokeCap.round;
final rect = Offset.zero & size;
canvas.drawArc(rect.deflate(5), -math.pi / 2, math.pi * 2 * value, false, stroke);
}
@override
bool shouldRepaint(ProgressRingPainter oldDelegate) => oldDelegate.value != value;
}Production practice
Contract
Define the efficient accessible chart inputs, outputs, owner, lifecycle, visible states, and platform assumptions before selecting APIs or packages.
Verification
Protect pure rules with unit tests and the rendered public contract with widget or integration evidence; include one unavailable or failure case.
Operations
Keep dependencies replaceable, log actionable context without user secrets, and measure user-visible behavior before optimizing.
Common failure mode
Independent workshop
Extend the guided lab into a review-ready efficient accessible chart feature that fits the running course portfolio app.
Your finished workshop must include:
- Canvas
- Paint and paths
- CustomPainter
- Repaint contracts
- Hit testing
- Automated verification and a short design note
Definition of done
Recap & quick check
Key takeaways
- Canvas: Use when normal widgets cannot express the graphic efficiently
- shouldRepaint: Compare every field that affects drawing
- Semantic alternative: Pair custom charts with a concise label or data table
Quick check
1. Which rule best applies to Canvas?
2. Which rule best applies to shouldRepaint?
3. Which rule best applies to Semantic alternative?
Next: Slivers & Advanced Scrolling