On Wed, 1 Feb 2023 10:15:36 GMT, Florian Kirmaier <fkirma...@openjdk.org> wrote:
>> After thinking about this issue for some time, I've now got a solution. >> I know put the scene in the state it is, before is was shown, when the >> dirtyNodes are unset, the whole scene is basically considered dirty. >> This has the drawback of rerendering, whenever a window is "reshown", but it >> restores sanity about memory behaviour, which should be considered more >> important. > > Florian Kirmaier has updated the pull request incrementally with one > additional commit since the last revision: > > JDK-8269907 > renamed testclass, based on code review, > readded acidentally removed import Adding to the above, I couldn't find in what cases `Node` might be referred from `NGNode`. Where is this happening? Further, `NGNode` only has a parent pointer, not a full parent/child hierarchy like `Parent` has. This would mean that if you track `NGNode` in `Parent#removed` a big part of the problem is alleviated as only a few parent `NGNode` will be unable to be GC'd, versus entire UI trees when you refer to `Node`. I also did some more digging, and the only thing that the dirty region computation for removed nodes really requires is a `RectBounds`. To do this it accesses only a couple of fields of `NGNode`, no heavy calculations are involved in this part and so this could be done right away -- it's also possible that `Node` may already have this information in some form (basically we need to know the last bounds of the node when it was rendered on screen -- saving a copy in the `doUpdatePeer` call may be sufficient). When the dirty area computation for the parent is performed, you'd only need to apply the transforms and clipping logic that the parent provides on this `RectBounds` -- no further fields of the removed `NGNode` would need to be accessed. ------------- PR: https://git.openjdk.org/jfx/pull/584
