All language subtitles for 9. Understanding the Repaint Rainbow

So what's the repaint rainbow here?

I activated it and the result is that

now if I do something in the app like tap a button, I get some borders here and these borders indicate

what was repainted

and the more often something gets repainted, the more often the color around that widget changes

and therefore this is a great tool for finding out whether something changed on the screen

that shouldn't really change.

For example here when I click the buttons, it makes sense that

all this part here changes. However in our application here, since we manage the entire state in the

main.dart file in MyAppState class which is connected to our root, to our topmost widget, the MyApp

widget, since we manage our core state

in here, we always rebuild the entire app and the entire page with every button click.

That's the reason why we also see boundaries or borders, green borders around our appBar for example

because that's also rebuilt when our chosen question changes.

Now that's normal for this application here and it's okay for this simple app but a possible improvement

here could be to wrap our core quizzing logic, with the quiz and the result, into a separate widget which

then manages the state, so that the scaffold and MaterialApp and appBar widget are in a separate widget

where the state is not managed, so that the build method for this widget which contains these never changing

elements is never triggered

and we have the things that do change in a separate widget. That would be one possible optimization which

won't matter here but which we will apply later in the more complex apps we're building to ensure that

we really only trigger the build method on the widgets that did change and not trigger it on unrelated

widgets which don't really need to update because in this app, the appBar never changes,

there is no need to trigger build for it and therefore repaint it on the screen.

One important side note at this point though, repainting on the screen is not the same as recreating

it.

It's of course great if you can avoid it being repainted, for example by outsourcing the parts that do

change into separate widgets

but even if something is repainted, Flutter might be able to simply take the previous element it painted,

so the previous appBar with the exact same color and text and reapply that, then it's still worse than

not repainting it but it's better than recreating it, which would mean that it also had to internally

rebuild the appBar, which takes up a bit more performance than just drawing an element which it already

knows which it already has stored in memory back onto the screen.

It's a small difference but it does matter. An element might be repainted but Flutter might be able to

take an existing element from memory that's better than if Flutter has to create a new element and then

paint that element. Of course, the best is if Flutter neither has to recreate nor repaint an element but

we'll take a closer look at such optimizations later once we're a bit more advanced and we know a bit

more about Flutter.