Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
bugfix: block states sometimes were inconsistent when decreasing reso…
…lution An assumption was made that there is always at least one VISIBLE block in a subtree of the REMOVED node. However, this assumption was too strong and it's not always true: for example, consider the following block tree: REMOVED #1 -> REMOVED #2 -> VISIBLE #3. For example, in the next scene update the VISIBLE block #3 goes outside the screen so it's excluded from the requested tree, while it's neighboring block #4 with the same parent node #2 that was outside the screen is now inside, so it's added as a new leaf node in the PENDING state. The updated block tree becomes: REMOVED #1 -> REMOVED #2 -> PENDING #4. Then in the next scene update the resolution needs to decrease, so that the root block #1 now becomes the leaf of the requested tree, and its state is set to PENDING. The algorithm needs to keep all VISIBLE leaf nodes and its ancestors in the subtree of this block #1, and it mistakenly keeps the block #2 under the incorrect assumption mentioned above (assuming that there is a VISIBLE block somewhere below in the subtree), while there is only the PENDING block #4. Then the PENDING block #4 is excluded from the new configuration because it's not needed anymore, and the REMOVED block #2 ends up being the leaf node which is an inconsistent state. With this fix, the block #2 will be excluded from the updated block tree configuration as well because there are no VISIBLE blocks in its subtree, and all the resulting states will be valid.
- Loading branch information