RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty

[John Hendrikx]

On Mon, 6 May 2024 14:14:05 GMT, eduardsdv <duke at openjdk.org> wrote:

> This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310.
> 
> This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. 
> Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method.
> 
> Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. 
> This guarantees:
> 1. that all dirty flags are removed after rendering, and 
> 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing.
> Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``.
> 
> The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR.
> 
> The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest``

Even though this fix is more intrusive, it does seem to address the root cause.  Instead of cleaning dirty bits in many places where it is easy to miss one, it always occurs only exactly where needed (after painting completes) using a method that can't accidentally miss parts.

At a minimum I think the tests that are part of this PR should be included in FX whichever fix ends up being integrated.

A quick glance doesn't turn up anything unexpected.  I'm only wondering if the code in `paintImpl` should always clear the dirty bits even if an exception occurs during painting, to harden it against potential bugs and not end up trying to repaint again and again likely getting the same exception again and again.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2117594606