That sounds reasonable to me. I remember game loops being split into one draw() and one update() function and would expect UI frameworks to be the same. I thin

That sounds reasonable to me. I remember game loops being split into one draw() and one update() function and would expect UI frameworks to be the same. I think, in games, it's usual to traverse twice through each object in a graph on each loop, once for drawing and once for updating/handling interactions. Am I right guessing that UI frameworks do something similar? One update function traversing through each widget to check for interactions. Then two drawing-related functions, with one checking for each object whether it changed and needs to be redrawn, and the second drawing just those widgets that changed? I'm trying to think in terms of Big O, and it doesn't sound unreasonable to drop the change-calcylation function and redraw from scratch because that way you would have two O(n) functions instead of three. Maybe the constant factor of drawing pixels to the screen is high enough to outweigh that additional change-detection loop.