An “update” here refers to recalculating the data necessary to render something (e.g. the position/rotation/scale and then transform updates, whose data is sent to the renderer).
Famous 0.3.5 ran every update on every frame. This led to a very easy developer experience but was a bit crazy. Consider 50 nodes with 5 components each, that’s 250 updates per frame, and at 60 fps, is 15,000 updates (all with their own calculation logic) a second. As the limitations with this were made clear, a
_dirty property was added to components to decide whether they needed to be updated.
In Famous 0.5+, you need to call
this._node.requestUpdateOnNextTick(this._id);. This implies that components must specifically request an update, but from discussion in the channel on github it’s actually more like the older model, see e.g. @andrewreedy’s comments in famous/engine#464 - High CPU usage in Cordova iOS webview.
I know that @joe proposed that updates should be opt-out rather than opt-in, since it’s a more positive developer experience.
I know also my own opinion is that I prefer opt-in. In my mind, I think it’s worth picking a few things that have a big impact on performance and forcing patterns that promote high performance. Obviously nothing that makes in unpleasant to code or a barrier to entry (for those kind of things, we can have a doc about “Performance Optimizations”), but I think it’s ok for a few critical things to be pushed. In
famin, from within a component, it’s just