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