[SWINGX-1442] Fix scalability when expanding a very large treetable Created: 03/May/11  Updated: 26/Aug/11  Resolved: 20/Aug/11

Status: Resolved
Project: swingx
Component/s: TreeTable
Affects Version/s: 1.6.2
Fix Version/s: 1.6.3

Type: Improvement Priority: Major
Reporter: permeable Assignee: kleopatra
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Mac OS X,
% java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-10M3326)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode)

Issue Links:
is related to SWINGX-1467 JXTree: support expandAll for large t... Open


I fixed a problem with expanding all of the nodes in a very large JXTreeTable. The problem is that JXTreeTable.expandAll() ends up calling TreeTableCellRenderer.getExpandedDescendants() for every expanded node; and it is recursive which make it very expensive. It takes a couple of minutes to open 25K nodes with four levels of descendents.

The fix is to override getExpandedDescendants() so that it does nothing during an expandAll()

Index: swingx-core/src/main/java/org/jdesktop/swingx/JXTreeTable.java
— swingx-core/src/main/java/org/jdesktop/swingx/JXTreeTable.java (revision )
+++ swingx-core/src/main/java/org/jdesktop/swingx/JXTreeTable.java (revision )
@@ -135,7 +135,7 @@

  • {@link #isHierarchical(int) hierarchical}


  • renderer extends JXTree and implements TableCellRenderer
  • private TreeTableCellRenderer renderer;
    + protected TreeTableCellRenderer renderer;


  • Editor used to edit cells within the
    @@ -2555,7 +2555,7 @@
    private JXTreeTable treeTable = null; // logically immutable
  • static class TreeTableCellRenderer extends JXTree implements
    + public static class TreeTableCellRenderer extends JXTree implements
    // need to implement RolloverRenderer
    // PENDING JW: method name clash rolloverRenderer.isEnabled and
    @@ -2603,8 +2603,17 @@
    return shouldApplyDropHack() ? false : super.isVisible();

+ public boolean skipExpandedDescendants = false;

+ @Override
+ public Enumeration<TreePath> getExpandedDescendants(TreePath parent) {
+ if (skipExpandedDescendants)

{ + return null; + }

+ return super.getExpandedDescendants(parent); //To change body of overridden methods use File | Settings | File Templates.
+ }

Comment by kleopatra [ 20/Aug/11 ]

thanks for your contribution

Tend to not apply it, though, as it is kind of hackish and might prevent proper state synch between the tree and its state as kept in the ui-delegate.

The method by itself is not meant for handling large and/or deep trees (note to myself: better document) - in such a case application code needs to take special care to not block the ui by doing the expand in the background and reporting back to the ui as appropriate.

A long standing task (don't recall if we ever formally opened an issue for it) is to support that background expansion somehow: however long it takes, the user only sees a small viewport of the total tree. So the task would imply some "intelligent" expanding near the current scroll position.

Ideas welcome


Comment by permeable [ 21/Aug/11 ]

I did not expect my change to be accepted for the same reasons you mention. My manager asked me to contribute my change back to the project. It is the simplest solution, not the most-correct. I look forward to the completion of the long standing task to support background expansion. Thanks.

Comment by kleopatra [ 24/Aug/11 ]

fair enough, and thanks again for bringing it up and providing a hack

BTW, started a discussion at swinglabs forum

Generated at Thu Apr 27 23:24:50 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.