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

[eduardsdv]

This is an alternative solution to the PR: #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

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issues

• JDK-8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty (Bug - P4)
• JDK-8332040: Parts of SG no longer update during rendering - overlapping - culling - dirty (CSR) (Withdrawn)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1451/head:pull/1451
$ git checkout pull/1451

Update a local copy of the PR:
$ git checkout pull/1451
$ git pull https://git.openjdk.org/jfx.git pull/1451/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1451

View PR using the GUI difftool:
$ git pr show -t 1451

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1451.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back eduardsdv! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[mlbridge]

Webrevs

• 00: Full (8aed95aa)

[kevinrushforth]

Reviewers: @lukostyra @arapte

This is a more intrusive fix than #1310 so we would only want to go this route if we can show that it is a correct fix, introduces no regressions (in either correctness or performance), and makes it easier to maintain in the future.

/reviewers 2

[openjdk]

@kevinrushforth
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).

[kevinrushforth]

/csr unneeded

[openjdk]

@kevinrushforth The CSR requirement cannot be removed as CSR issues already exist. Please withdraw JDK-8332040 and then use the command /csr unneeded again.

[kevinrushforth]

/csr unneeded

[openjdk]

@kevinrushforth determined that a CSR request is not needed for this pull request.

[hjohn]

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.

[eduardsdv]

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

The test has already been added to both PRs.

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.

Hm, that can indeed happen. On the other hand, if the dirty flag is reset even in the case of an exception, parts of the UI may not be updated for a long time until a node in that area receives a change. The question is which of these two options is the least harmful.

I'm fine with each of them. What do the others think?

[kevinrushforth]

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.

Hm, that can indeed happen. On the other hand, if the dirty flag is reset even in the case of an exception, parts of the UI may not be updated for a long time until a node in that area receives a change. The question is which of these two options is the least harmful.

I'm fine with each of them. What do the others think?

I'd probably lean towards addressing this in a follow-up issue, if there turns out to be a need.

@arapte can you look at this when you review it?