[Development] QProperty and when evaluation occurs

[Volker Hilsheimer]

> On 23 Jul 2020, at 15:56, Stottlemyer, Brett (B.S.) <bstottle at ford.com> wrote:
> 
> Hi,
> 
> I'm still trying to wrap my head around this concept, and starting a new thread to distinguish from the technical implementation discussion.
> 
> The two obvious cases:
> * Immediate evaluation.  This is the current signal-based handling (ignoring queued for the moment).
> * Evaluate-on-Read (EoR).  True lazy evaluation, where computations would never be made if no one asks.  Kind of the opposite of CoW.
> 
> EoR, though, seems not too useful in many cases; it seems to shift backwards towards polling.  I expect Qt's HMI technologies (Widgets, QML, 3D) to have to shift(?) to the third case:
> * Render evaluation.  When the render runs (nominally 30 or 60 frames per second), all "dirty" elements are evaluated, and the dirty flag is cleared.  In this case, the evaluation is lazy, but the task of figuring out when to evaluate is handled by the renderer, not passed on to the user.


The renderer operates on a scene graph data structure, which in turn is manipulated as the QML engine executes code and responds to events. Those data structures will ask for the data needed, when it’s needed. See Ulf’s layout example from the email starting the first thread.

FWIW, pull-based systems are *much* more scalable than push-based systems, because data is produced at the rate it can be consumed, not at the rate it can be produced. That is unrelated to polling.


> How about:
> * EventLoop evaluation.  Using area (or volume) as an example, a value depends on multiple variables that may all change, and calculating intermediate values before all updates are available is wasted cycles.  In this case, the changes are programmatic such that at the end of the eventloop, the value can be computed.


But why would we calculate the volume if nobody cares about the volume? :)


> Ok, so what?  I will assert that QObjects should use EventLoop evaluation if they have derived properties (like area()).  An HMI or app that combines data from multiple objects will have to be responsible for how and when the evaluation of those elements is done.  But a QObject, intended to be used by others, seems like it needs a better interface than a property that gets marked "dirty".  Could something like `Qt::makeLoopPropertyBinding` (note the Loop) be implemented?  Such that the property is evaluated at the end of the eventoop, and if changed/dirty, a signal is emitted at that point (possibly along the lines of QSingleShot(0))?
> 
> This assumes part of the intent is to enable QObjects with derived properties at an interface level...
> 
> Thoughts?


Leaving multi-threading and a few exceptions aside, all stack traces in Qt start in the event loop. The user clicked a button, a timer timed out, some data arrived at the network. Nothing happens in a Qt application if there is no event waking up the loop.

The code that handles those events will ultimately end up asking various objects for their properties. In the paint event (or scene-graph equivalent) at the latest, visible objects will be asked for that. Objects and properties that are never queried might just as well be in an “unknown” state forever.


Volker