[Development] Property bindings in Qt 6

[Chris Adams]

Hi Uwe,

On Sat, Sep 28, 2019 at 9:29 PM Uwe Rathmann <Uwe.Rathmann at tigertal.de> wrote:
>
> On 9/28/19 8:49 AM, Simon Hausmann wrote:
>
> > Instead of an idle timer, all imperative triggered onFooChange
> > handlers are queued up and called right before the next frame.
>
> Property binding is not the only notification mechanism and if its
> synchronous character is not appropriate for a specific situation, the
> correct solution could also be to use a different type of notification.
>
> F.e. the Qt/Quick layout system is based on binding the implicitSize
> while QWidgets or QSkinny indicate layout relevant changes by sending
> a QEvent::LayoutRequest to the parent.
>
> In the specific situation of Qt/Quick you know, that you don't need to
> do any layout recalculation before the next frame and as the
> documentation of QQuickItem::updatePolish states - "This function should
> perform any layout as required for this item." - it is an obvious
> implementation to simply call polish + posting a LayoutRequest, when
> receiving a LayoutRequest.

I might be misunderstanding you, but I think I agree in principle -
assuming that the item knows that it doesn't need to do its layout
recalculating this frame.  I guess the question becomes: should
individual items have to know/track this, based on state introspection
(where that might depend on the value of properties of some parent in
its parent change, e.g. visible), or should the engine track this and
avoid evaluating whatever might trigger the original polish in the
first place?

> So in general everything is prepared to do it in an efficient way,
> only the Qt/Quick controls/positioners/layouts don't do the obvious.
>
> Using a different type of property binding instead does not fix the
> actual design flaw: indicating that the implicit size has changed does
> not require calculating it in advance !

Maybe I'm misunderstanding again, but that's what the binding is
supposed to implement (a change to a dependency marks the binding as
dirty but doesn't trigger its evaluation until the property which owns
the binding is accessed, at which point the binding is evaluated).

> I guess the majority of the problems you want to solve with
> delaying the execution of property bindings are related to layout
> recalculations and once those are gone you don't have to change the
> synchronous character of property bindings anymore.

I agree that "unneeded" layout recalculations are a large contributor
to evaluation time spent, especially due to e.g. animations etc.  More
detailed benchmarks on real-world cases would be needed to determine
what percentage of evaluation is due to what, I guess, and thus which
potential solutions are likely to offer the most gain.

> Beside that it is a questionable assumption, that all property bindings
> are related to the next frame and that processing the bindings right
> before the next frame is the right point in time. It might delay
> bindings that should be done earlier, but also hurt the frame rate as
> entering the scene graph thread might be blocked by calculations, that
> should better have been in between frame updates, where the CPU was idle.

Right, while delayed evaluation it might be a step in the right
direction (i.e. avoiding duplicated work) it does miss a lot of
potential gains (i.e. avoiding work which doesn't need to be done at
all) and introduce a potential problem (reduced timeslice for critical
path evaluation) assuming that I understand the proposal (which I may
not, properly).  And I agree that idle-time processing of dirty
sections of the graphs is likely to be a win, but requires some way to
determine whether the evaluation is in fact needed before the next
frame, or not - and the cost of that determination must be less than
the cost of simply evaluating the bindings synchronously, on average..

> On a general note: IMHO you ( = Qt development ) could be more
> courageous than trying to solve all and everything in the QML runtime
> engine only - even if you have to touch code, where the authors are gone.
>
> My 2 cents,
> Uwe
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development