[codyd51]

Yes, you're absolutely correct! The design here totally suffers from unbounded memory use if you draw onto a large canvas. (Restating parts of your comment for confirmation that this is also how I think about it.)

To resolve this while maintaining the spirit of the design, I think two representations need to be kept: one for the rendered pixel data, and one 'out of band' representation (such as the textual data - you also highlighted this in your comment).

The idea is that, when the pixel buffer memory gets too large, some of it can be dropped. When it scrolls back into view again, it can be repopulated by the secondary representation. What I don't like about this is how it doesn't feel like it generalises well - you always need to be able to store the secondary representation, and have code to redraw it.

I think the concept you suggested is a really good one: just make sure everything that's drawn is its own 'encapsulated' widget with its own drawing logic, and you can ask it to render itself whenever that's convenient. I'm grateful for the input here, and think I will end up switching to this sort of approach in the future.

[tomsmeding]

I'm not sure "correct" engineering really fits UEFIRC, somehow :p

But if it's fun, go ahead! Perhaps it's helpful for axle too. :)