[Development] QProperty and when evaluation occurs

[Filippo Cucchetto]

Hi Brett,
if I understood correctly what you wrote you're basically asking how
to handle the scenario of an observer of a QProperty (given that it
recomputes its value only if someone reads it).
By your example i would assume that basically you can achieve what you
want with a QTimer(0) that re/reads all your QProperties.

That said it seems to me that *Render Evaluation* is the way QtQuick
will use QProperty. The only drawback I see it's possible computation
spikes before frame rendering.
Keep in mind that often properties evaluate multiple times before
arriving at a stable point.

F.

Il giorno gio 23 lug 2020 alle ore 15:58 Stottlemyer, Brett (B.S.)
<bstottle at ford.com> ha scritto:
>
> 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.
>
> 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.
>
> 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?
>
> Regards,
> Brett
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development



-- 
Filippo Cucchetto