Hi Uwe, On Sat, Sep 28, 2019 at 9:29 PM Uwe Rathmann <uwe.rathm...@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@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development