dphfox
commented
1 year ago Implicit frame deferral seems to cause a lot of confusion, problems and visual desync. I think the correct thing to do is to assign directly to properties, and instead allow for deferred evaluation as stated above for when it's absolutely needed. In reality, transactions and batching could probably achieve much of the same efficiency gains (#150)
From watching people use Fusion, and from some of my own experiences with the library, one thing I've noticed get in the way sometimes is how Fusion defers property changes until the next resumption cycle/render step.
The original motivation for this was to mitigate the cost of having many quick changes to the property before its shown, however the performance gain here is somewhat questionable for most UIs and it leads to unintuitive and often unhelpful off-by-one frame behaviour when observing the behaviour of the instance. This isn't usually game breaking but it can sometimes cause unattractive lag and visual desync for some visual elements.
With features such as #150 however, we're looking at alternate solutions for allowing users to control when updates are dispatched for the reactive graph itself to improve efficiency. In light of this, perhaps it might be worth removing frame deferral by default and moving this responsibility onto users.
Its worth noting the reactive graph already terminates updates that don't result in changes, so at least when dealing with a single transaction, frame deferral becomes redundant. Furthermore it seems sensible at first thought to assume that there are a reasonably small number of transactions per frame usually, which should be perfectly fine performance wise.
If it turns out that this kind of behaviour is sorely needed for some kind of use case, we could always reintroduce this mechanic as a dedicated state object which defers any updates to the next render step.
Having it as a dedicated state object external to the instance API means that pure data workflows can take advantage of this. If needed, it can also be used to replicate the old behaviour of frame deferral where required. But above all else, its also much more visible, obvious and controllable, which would make handling frame deferral much easier in theory.