Where is the doc on migration from synchronous to deferred/batched reactions/effects?
-
(I may not have the right terminology, it's been a while since I've been here).
I remember that at one point, Qt made a fundamental change to reactivity, by making effects happen deferred rather than synchronously, for better performance (not running reactions too many times unnecessarily). It may have had to do with QML, but I don't recall.
Where is the article or document that described this notable change? I'm having a hard time Googling for it.
EDITS:
Was it the
QueuedConnectionfeature perhaps? Was it the firing of reactive JS expressions in QML?Hmm, in https://doc.qt.io/qt-5/qtquick-performance.html, it says
If you have a loop where you do some processing, but only the final result of the processing is important, it is often better to update a temporary accumulator which you afterwards assign to the property you need to update, rather than incrementally updating the property itself, in order to avoid triggering re-evaluation of binding expressions during the intermediate stages of accumulation.
I could have sworn this was the problem the feature that I'm remembering was supposed to solve, so that reactions would be batched in a future "task" (in JavaScript, it would be a microtask). I just don't remember where I read about this, or the terms used.
Right now, the only feature I can find is
QueuedConnection, and that if using that by default for all signal/slot connections, we'll be able to avoid a similar problem as described for QML property binding.Is this the only feature? Or was there another one, relating to deferring/batching updates?
-
Perhaps you are referring to texture atlas changes which landed many many years ago https://www.qt.io/blog/2013/09/02/new-scene-graph-renderer
-
Perhaps you are referring to texture atlas changes which landed many many years ago https://www.qt.io/blog/2013/09/02/new-scene-graph-renderer
@sierdzio hey, thanks. That does mention batching I n the renderer. What I remember though was an article that described a fundamental change to user code because reaction timing was changed such that reactions are deferred and batched. I can't find it, maybe because I don't remember the terms to search for. It was years ago indeed. Maybe it was another framework, although I thought it was Qt if I recall correctly. Plus the old sites and links pre-qt.io are gone, so maybe that makes it harder to find if it still exists, if my memory of it being Qt is correct.
-
Hmm then maybe you are referring to new C++ bindable properties https://www.qt.io/blog/all-about-property-bindings-in-qt-6.2
-
Hmm then maybe you are referring to new C++ bindable properties https://www.qt.io/blog/all-about-property-bindings-in-qt-6.2
@sierdzio Hmm, that indeed seems very similar to what I was asking about, and indeed describes the difference between synchronous-wanting code and the deferred dispatching. But in my mind I recall it being several years ago; by 2015 I got focused on web-based development.
Was the deferred/lazy behavior also default for QML at any point?
-
Hmm yeah, looks like it was Qt 6: https://www.qt.io/blog/property-bindings-in-qt-6. Although in the 6.0 release post, which is what I was searching in when I opened the topic, it wasn't mentioned. I didn't think to search "property bindings deferred". That would have found it. The terms we've been using in web projects is reactive variables or "signals", and dependency-tracking effects or reactive computations.
Did that deferred behavior apply to QML bindings too in 6.0?
-
Property bindings in QML were always deferred. Kind of.
Not sure, sorry :D
