Should be enough to just tell the renderer to refresh (even recreate?) the image of a changed entity (or all the entities), rather than performing each individual transformation on the cached image(s) directly, in sync with the original model transformations! ("Refreshing" means only updating the cached image, not actually drawing (rendering) anything.)
And then later, if that happens to still become a perf. bottleneck, only then, there could be some extra optimizations (re)introduced.
Note: there's an implicit assumption/distinction here that some of the transformations are not cheap, i.e. don't map directly from model object state to rendered shape -- unlike cheap ones, like positions, which are best processed right in the drawing step. But in fact, all the usual basic props like size, rotation should be the same, not needing any interim syncing at all, just a "cold" update batch for each changed object (so a changed flag would still be handy! :) ).
Anyway, for all the cheap transformations to be applicable to the rendering shapes, the model objects should still be explicitly designed to use the same transformations, or be trivially transformable to their rendered shapes.
(Alternatively, keep track of model delta transformations, if that's cheaper to apply to the rendered shapes.)
Another assumption for a batched (pre-draw) update_changed_shapes() rendering op. to make sense is that multiple accumulating changes to the same objects are expected. If this is not true, then indeed, an individual direct call to update the rendered shape right when the model is being changed, could be better: would spare the changed flags, and the extra loop of going through them!
It also depends on the cache profile etc. of both the model update loop and tampering with the rendered shapes. Shape-updates "while the object is hot" could be optimal, if those shape updates -- which are out-of-context for model updates! -- don't cool the CPU down much in the inner model update loop.
Should be enough to just tell the renderer to refresh (even recreate?) the image of a changed entity (or all the entities), rather than performing each individual transformation on the cached image(s) directly, in sync with the original model transformations! ("Refreshing" means only updating the cached image, not actually drawing (rendering) anything.)
And then later, if that happens to still become a perf. bottleneck, only then, there could be some extra optimizations (re)introduced.
Note: there's an implicit assumption/distinction here that some of the transformations are not cheap, i.e. don't map directly from model object state to rendered shape -- unlike cheap ones, like positions, which are best processed right in the drawing step. But in fact, all the usual basic props like size, rotation should be the same, not needing any interim syncing at all, just a "cold" update batch for each changed object (so a
changedflag would still be handy! :) ).Anyway, for all the cheap transformations to be applicable to the rendering shapes, the model objects should still be explicitly designed to use the same transformations, or be trivially transformable to their rendered shapes.
(Alternatively, keep track of model delta transformations, if that's cheaper to apply to the rendered shapes.)
Another assumption for a batched (pre-draw)
update_changed_shapes()rendering op. to make sense is that multiple accumulating changes to the same objects are expected. If this is not true, then indeed, an individual direct call to update the rendered shape right when the model is being changed, could be better: would spare thechangedflags, and the extra loop of going through them! It also depends on the cache profile etc. of both the model update loop and tampering with the rendered shapes. Shape-updates "while the object is hot" could be optimal, if those shape updates -- which are out-of-context for model updates! -- don't cool the CPU down much in the inner model update loop.