VirtualizedScrollPane causes high CPU and GPU on idle with 125% screen scaling

[fthevenet]

When using a control embedded inside a VirtualizedScrollPane with the upcoming release 16 of JavaFX, then it is possible under specific circumstances that the method layoutChildren() becomes perpetually invoked, causing high CPU and GPU usage even when the application is idle.

These conditions are:

• Using openJFX 16 or higher at runtime
• The effective screen scale at which the window is rendered is not a multiple of 100% (i.e. 125%, 150% or 175%, etc...).
• The horizontal scrollbar is displayed.

The following code sample illustrates the issue, when run under javafx 16, with for instance a 125% scale (you can force it with -Dglass.win.uiScale=1.25 or -Dglass.gtk.uiScale=1.25, on windows or linux, respectively):

public class TextScroll extends Application {
    private final static String LONG_LINE_OF_TEXT = "Lorem ipsum dolor sit amet, consectetur adipiscing elit. " +
            "Nulla viverra fringilla dictum. Integer faucibus laoreet nulla eget vehicula. " +
            "Vivamus et arcu eget metus interdum tincidunt ac sed libero. Phasellus vestibulum" ;

    @Override
    public void start(Stage stage) throws Exception {
        var textArea = new CodeArea();
        textArea.replaceText(LONG_LINE_OF_TEXT);
        Scene scene = new Scene(new VirtualizedScrollPane<>(textArea), 800, 600);
        stage.setScene(scene);
        stage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}

The root cause for this, is that the VirtualizedScrollPane request a layout when the height of the horizontal scroll bar changes but in the course and the layout, the calculated value for this height changes, which in turns triggers a request layout, etc...

This is due to the fact that a bug was fixed in JavaFX 16 (https://bugs.openjdk.java.net/browse/JDK-8211294) where the mechanism which snaps coordinates to actual pixels on screen with a non integer scale factor was broken; this is now fixed in javaFX, but Flowless remains unaware of the need for enforcing snapping, which causes some coordinates calculated in Flowless to be rounded differently that their equivalent in JavaFX; in this case this is what caused the scrollbar height to be different in two nested calls to layoutChildren, and lead to the constant layout.

A solution is to use snapSize() method to ensure height and width are snapped (i.e. ceil'd) to pixels consistently with JavaFX.

(NB: Ideally, we'd want to use snapSizeX() and snapSizeY() instead of the deprecated snapSize() so that we properly support non square screen ratio, but this is not available in JavaFX 8 that Flowless is built against.)

[Jugen]

Hi @fthevenet, thanks for the detailed bug report.

I'm not the original author but I am the current maintainer, so if you submit a PR with your suggestion I'll gladly merge it.
Otherwise if you could point out the exact code that needs to change I can also submit the PR.

Thanks.

[fthevenet]

Hi @Jugen

I've submitted PR #82 that should address the issue.

[fthevenet]

Hello @Jugen

Do you have an ETA for a release that includes this fix (and a subsequent release of RichTextFX)?

As mentioned in the OP, this issue does not manifests itself in versions of JavaFX prior to the upcoming 16.
With that said, GA for OpenJFX 16 getting quite close now (planned for March 9, 2021); I think it would be ideal if this could if this could be ready by then.
Of course, I'm well aware that there's often a gap in between what's ideal and what's realistic, so hopefully this doesn't come across as pushy.

If I can be of any further assistance on that matter, please let me know.

-- Fred.

[Jugen]

Hey Fred, thanks for the prompting .... 0.6.3 has been released now.
May take a day or two to appear on Maven though.
RichTextFX may follow in the next week or two .....

[fthevenet]

That's great; thanks a lot!

-- Fred.

[Col-E]

Edit: Disregard, I miss-attributed the problem. My issue was another component with an animation that visually did nothing, but kept re-triggering scene layouts.