The animation-driven repainting with
BarChartPainter is set up in this line which contains a call to the constructor of
CustomPainter with the
Animation<Bar> as argument. See the relevant Flutter API documentation here. There is no Dart magic involved, just a call to a superclass constructor.
More details below, in case you are interested.
The detailed history involves the
RenderObject concept which I did not discuss in my article, as it is a lower-level concept in the Flutter architecture. Many widgets are backed by a
RenderObject which is responsible for rendering the widget, that is, for handling the lifecycle around layout and painting on the screen canvas.
So, the repainting of
BarChartPainter is actually accomplished in the implementation of the
CustomPaint widget that we configure with the
CustomPainter (in main.dart). The
RenderObject backing that widget attaches a listener on the
Animation, and schedules repaint using the
markNeedsPaint lifecycle method of
RenderObject on each animation tick. The relevant line in the current Flutter implementation is here.
When a new frame is due, each "dirty”
RenderObject is asked by the Flutter framework to paint itself onto the screen, and ours will then delegate to the
CustomPainter subclass that we wrote.