Re: how to implement delayed calculation of node/shape
>From Scene doc: "The scene graph detects dynamic node changes which affect layout (such as a change in size or content) and calls requestLayout(), which marks that branch as needing layout so that on the next pulse, a top-down layout pass is executed on that branch by invoking layout() on that branch's root. During that layout pass, the layoutChildren() callback method will be called on each parent to layout its children. This mechanism is designed to maximize layout efficiency by ensuring multiple layout requests are coalesced and processed in a single pass rather than executing re-layout on on each minute change." Parent class has a layoutChildren() method that can be overriden. Do you mean processing my own classes here depending on their dirty state? If not, can you elaborate on that suggestion? Thanks. On Mon, Aug 27, 2018 at 12:16 PM Tom Schindl wrote: > Why not do the necessary stuff on the next layout-pass? > > Tom > > On 27.08.18 09:48, Zsolt Kúti wrote: > > Thank you for the idea, I'll explore it. > > > > On Sun, Aug 26, 2018 at 5:16 PM Michael Paus wrote: > > > >> One possible solution for this would be to use an AnimationTimer. > >> Maintain a dirty state somewhere and check that when the AnimationTimer > >> gets called for the next pulse. > >> > >> Am 26.08.18 um 16:59 schrieb Zsolt Kúti: > >>> Hi, > >>> Some of my classes extend Path or Group and constructed by non-trivial > >>> algorithms that may use many properties, either standard (like > >> strokeWidth) > >>> or non-standard ones. Setting a property calculates a new state at > >> present. > >>> When several properties are set it means a lot of unnecessary > >> calculations > >>> done. > >>> > >>> I would like to delay geometry/shape calculations similar the way > >>> Node/Shape do. They signal their state changes by dirty flagging and on > >>> pulse necessary synchronization does recalculations when being dirty. > >>> However relevant methods despite being public are deprecated (tipically > >>> ones starting with impl_) and cannot be relied upon. > >>> > >>> Is there a way to achive that kind of design for own classes? > >>> Thx! > >>> > >>> Zsolt > >> > >> > >> > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck >
Re: how to implement delayed calculation of node/shape
Why not do the necessary stuff on the next layout-pass? Tom On 27.08.18 09:48, Zsolt Kúti wrote: > Thank you for the idea, I'll explore it. > > On Sun, Aug 26, 2018 at 5:16 PM Michael Paus wrote: > >> One possible solution for this would be to use an AnimationTimer. >> Maintain a dirty state somewhere and check that when the AnimationTimer >> gets called for the next pulse. >> >> Am 26.08.18 um 16:59 schrieb Zsolt Kúti: >>> Hi, >>> Some of my classes extend Path or Group and constructed by non-trivial >>> algorithms that may use many properties, either standard (like >> strokeWidth) >>> or non-standard ones. Setting a property calculates a new state at >> present. >>> When several properties are set it means a lot of unnecessary >> calculations >>> done. >>> >>> I would like to delay geometry/shape calculations similar the way >>> Node/Shape do. They signal their state changes by dirty flagging and on >>> pulse necessary synchronization does recalculations when being dirty. >>> However relevant methods despite being public are deprecated (tipically >>> ones starting with impl_) and cannot be relied upon. >>> >>> Is there a way to achive that kind of design for own classes? >>> Thx! >>> >>> Zsolt >> >> >> -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: how to implement delayed calculation of node/shape
Thank you for the idea, I'll explore it. On Sun, Aug 26, 2018 at 5:16 PM Michael Paus wrote: > One possible solution for this would be to use an AnimationTimer. > Maintain a dirty state somewhere and check that when the AnimationTimer > gets called for the next pulse. > > Am 26.08.18 um 16:59 schrieb Zsolt Kúti: > > Hi, > > Some of my classes extend Path or Group and constructed by non-trivial > > algorithms that may use many properties, either standard (like > strokeWidth) > > or non-standard ones. Setting a property calculates a new state at > present. > > When several properties are set it means a lot of unnecessary > calculations > > done. > > > > I would like to delay geometry/shape calculations similar the way > > Node/Shape do. They signal their state changes by dirty flagging and on > > pulse necessary synchronization does recalculations when being dirty. > > However relevant methods despite being public are deprecated (tipically > > ones starting with impl_) and cannot be relied upon. > > > > Is there a way to achive that kind of design for own classes? > > Thx! > > > > Zsolt > > >
Re: how to implement delayed calculation of node/shape
One possible solution for this would be to use an AnimationTimer. Maintain a dirty state somewhere and check that when the AnimationTimer gets called for the next pulse. Am 26.08.18 um 16:59 schrieb Zsolt Kúti: Hi, Some of my classes extend Path or Group and constructed by non-trivial algorithms that may use many properties, either standard (like strokeWidth) or non-standard ones. Setting a property calculates a new state at present. When several properties are set it means a lot of unnecessary calculations done. I would like to delay geometry/shape calculations similar the way Node/Shape do. They signal their state changes by dirty flagging and on pulse necessary synchronization does recalculations when being dirty. However relevant methods despite being public are deprecated (tipically ones starting with impl_) and cannot be relied upon. Is there a way to achive that kind of design for own classes? Thx! Zsolt
