[Development] Property bindings in Qt 6

[Uwe Rathmann]

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.

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 !

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.

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.

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