I Have A Virtual ScrollPane Displays All I want, except I cant Click Any Items. Ima Currently Using Gridpane as the node in virtual flow,is that the way to Go ?

I didn't create this fix, but @StrangeNoises. It was never applied for some reason, but it should fix FXMisc/RichTextFX/issues/265.

I don't know if this is the "correct" way of fixing it or not, but it works as expected on my OSX machine.

How's this? I'm also not sure if there might be some unwanted implications of adding the Scale object to the ScaledVirtualized wrapper and not the Virtualized content itself

Coming from TomasMikula/RichTextFX#205, allow the option of not showing the horizontal and/or the vertical scrollBars.

Tomas already said in the above issue:

Hard-wiring auto-scrollbars into VirtualFlow didn't feel quite right from the start. On the other hand, the internal architecture of VirtualFlow already very much separates the scrollbar concern: VirtualFlow basically just adds scrollbars onto VirtualFlowContent

I didn't know what the final de-skinned form of RichTextFX would look like, so I decided to work one exposing its scroll properties. However, I can't expose the scrolling properties in RichTextFX unless VirtualFlow itself has them exposed.

Starting with javaFX 17-ea+11 I noticed that scrolling a StyledTextArea (from RichTextFX) no longer worked properly: when clicking the scroll bar elements, the text scrolls for the first couple of clicks and then entirely stop responding to clicks on these elements. It does respond to using the mouse wheel of keyboard arrows however.

https://user-images.githubusercontent.com/7450507/130807718-723b881d-1de7-4dcd-82d3-d95c4fa3848d.mp4

Since it did work with previous early access of jfx (up to 17-ea-9, actually), I did manage to pinpoint that change responsible: https://github.com/openjdk/jfx/pull/454

The above PR changes the type of listener used internally by the built-in bi-directional bindings, from ChangeListeners<T> to InvalidationListeners. This should be transparent to most if not all applications, but because Flowless relies on ReactFX, which interacts with bindings and events in a very intimate way, something was broken by that change.

I managed to workaround the issue in the VirtualizedScrollPane by replacing the affect bi-directional bindings by a couple of mirrored ChangeListeners.

I will submit a PR illustrating this workaround for your consideration.

Is it Possible To Itntoduce Negative Checks, As in some instances, I get Index Out Of Bounds Exception -1, with no cause, usually after being idle for a while,with a Huge List

VirtualFlow calculates a reasonable jump size when using the mouse wheel or scroll bar increment/decrement buttons. This leads to reasonable scrolling behaviour but with large content (e.g. a many page PDF) the scroll amount can be quite large, like 20 pixels or so, and this leads to a jerky feeling when scrolling.

Seeing as how ReactFX has the nice Val.animate() method it would probably be quite easy to fix this. I had a quick go at doing so without hacking Flowless itself but it seems the methods I'd need are all (package) private. Perhaps there's a simple trick to get this; I guess inserting a simple animated val with short duration between the desired scroll position and the actual position is sufficient.

Save the index of the first and last visible cell at layout time, and make them available via accessors. This allows much more efficient retrieval of this information.

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.)

Coming from TomasMikula/RichTextFX#205 and relating to #9, provide more access to VirtualizedScrollPane's objects so that layoutChildren can be better overridden.

There's a few ways this could be done:

• Complete freedom: make the (currently private) content, hbar, and vbar protected. Then the developer can fully layout the children as they desire.
• Restrict to content layout: since a developer will need to rewrite the scroll bar implementation each time he/she extends VirtualizedScrollPane (or more probably, screw up how the scroll bars get laid out), use a protected method to layout the content which developers can override:

protected void layoutChildren() {
    // normal layout code...

    // instead of "content.resize(w, h)" have
    layoutContent(w, h);

   // rest of method's code.
}

protected void layoutContent(double width, double height) {
    content.resize(width, height);
}

Running maven-javadoc-plugin with detectLinks set to true gives an error:

error: Error fetching URL: https://github.com/FXMisc/Flowless/#flowless/apidocs/ (java.io.FileNotFoundException: https://github.com/FXMisc/Flowless/package-list)

Is there a way to position the cells manually? I'm trying to create a tree structure. In a tree structure the children of a node are positioned slightly to the right of the parent. How can I tell Flowless to position the cell like that? Also, the space from the right depends on the level of the node, so it should be dynamic

Adding items too fast to item list of a VirtualFlow causes scroll if the item list is empty. Waiting few milliseconds after adding first item fixes the problem. Also calling visibleCells() method after adding first item fixes the problem but I don't know if its about time it takes or something else.

Demo:

public class Main extends Application {
    ObservableList<Integer> items = FXCollections.observableArrayList();
    VBox vbox = new VBox();
    Button add30Buttton = new Button("add 30");
    Button add1Button = new Button("add 1");
    Button removeAllButton = new Button("remove all");

    VirtualFlow<Integer, ?> virtualFlow = VirtualFlow.createVertical(items, i -> Cell.wrapNode(new Label(i.toString())));
    VirtualizedScrollPane<VirtualFlow<Integer, ?>> scrollPane = new VirtualizedScrollPane<>(virtualFlow);

    @Override
    public void start(Stage stage) {
        add30Buttton.setOnAction(event -> {
            items.add(0);
            // virtualFlow.visibleCells(); // uncommenting this fixes the problem
            for (int i = 1; i < 29; i++) { items.add(i); }
        });
        add1Button.setOnAction(event -> items.add(999));
        removeAllButton.setOnAction(event -> items.clear());

        VBox.setVgrow(scrollPane, Priority.ALWAYS);
        vbox.getChildren().addAll(add30Buttton, add1Button, removeAllButton, scrollPane);

        Scene scene = new Scene(vbox, 300, 400);
        stage.setScene(scene);
        stage.show();
    }

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

In the VirtualFlow class, there is no constructor but static methods taking a list of items and a mapping function to convert the items into Cells.

Are there any costs to performance if Node objects are passed in directly?

The vertical scroll lacks fluidity on OSX 10.11.6, while the horizontal scroll works as expected. I have this problem with the demos, with juliar, and with my apps that integrate RichTextFx See attached image for an illustration of the problem

This issue its related to RichTextFX/issues/657 and RichTextFX/issues/265, and the solution proposed by @StrangeNoises works for me on OSX.

The @StrangeNoises code is integrated in the last codebase at #57