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.) <bstot...@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@qt-project.org > https://lists.qt-project.org/listinfo/development -- Filippo Cucchetto _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
