The same happens with the following CSS rule from AtlantaFX from
https://github.com/mkpaz/atlantafx/blob/3ffaf3d24345c28d5abb3c9122698a1ee9727a9c/styles/src/components/_data.scss#L444:
// when in constrained resize mode, the right-most visible cell should
not have a right-border, // as it is not possible to get this cleanly
out of view without introducing horizontal scrollbars .table-view:constrained-resize>.virtual-flow>.clipped-container>.sheet>.table-row-cell>.table-cell:last-visible,
.tree-table-view:constrained-resize>.virtual-flow>.clipped-container>.sheet>.tree-table-row-cell>.tree-table-cell:last-visible
{
-fx-border-color:transparent;
}
When this rule is present, a focus change in a table cell causes the
whole scene root to be marked as dirty for me.
The table view I am using doesn't even have the :constrained-resize
pseudo class active, yet the rule still affects the behaviour. So I
assume that having multiple pseudoclasses in a CSS rule at different
places breaks something with the dirty region calculation. It might not
even be the wrong usage of pseudoclasses that causes issues
On 02/07/2026 14:20, Christopher Schnick wrote:
I enabled the property -Dprism.showdirty=true to troubleshoot some
performance issues of our application.
I found a case where the entire scene root node is marked as dirty
when pseudoclasses are used in a certain way. Since I am no expert
about the CSS implementation, I wanted to ask whether this is a bug.
The offending rule was:
.combo-box-base:hover .arrow-button:hover .arrow {
-fx-background-color:red;
}
Note that the hover pseudo class is used twice, was my mistake that
did go unnoticed. Whenever the hover state changed for the combo box,
the root was shown as dirty
When changing it to this, everything works as expected and only the
arrow is marked as dirty instead of the whole scene:
.combo-box-base > .arrow-button:hover .arrow {
-fx-background-color:red;
}
