[Development] QProperty and when evaluation occurs

Chris Adams chris.adams at qinetic.com.au
Fri Jul 24 02:55:43 CEST 2020


On Fri, Jul 24, 2020 at 5:17 AM Volker Hilsheimer <volker.hilsheimer at qt.io>

> > 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? :)

Metering evaluation (pre-evaluating subsections of the evaluation
dependency graph to avoid >16 ms spikes).  Of course, this can be done "on
top" of the lazy evaluation by generating targeted property reads within
the QML engine according to statistics it gathers, so I'm not arguing for
anything in particular, but just noting that it's an important use case
from a conceptual perspective.  Of course, this only applies if "nobody
cares about the volume [yet, but statistically are likely to within the
next few frames, during which time the volume is unlikely to change, but
when the volume is required, the total execution load would be likely to
exceed the compute budget for that frame, unless we precompute this
subsection of the graph]."

> > 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200724/673561d8/attachment.html>

More information about the Development mailing list