Skip to main content

J/X/Tree: expanding all nodes on a large tree on/off EDT?

3 replies [Last post]
kleopatra
Offline
Joined: 2003-06-11
Points: 0

Posted at OTN

https://forums.oracle.com/forums/thread.jspa?threadID=2273144

copied here for your convenience:

recently I was remembered of a long-standing task in SwingX, which is to support expanding all nodes of a JXTree .. for large trees.

http://java.net/jira/browse/SWINGX-1442

JXTree has api to do so, with a naive implemenation which simply loops through all rows until the end. That's good enough for smaller trees, but not for larger, can take minutes and is blocking the EDT.

Simple way is to tell the developer it's no good for larger trees, "your job to do it somehow in the background" ---  thinking about it, I couldn't come up with any idea about the how-to: expanding _is_ all ui-related touching several view-related classes including the tree itself during expansion, so looks like it has to happen on the EDT. Being so, the next option might be some way to partion the expansion into smaller chunks, each being so small that the effective blocking wouldn't be noticeable with some prioritizing such that the visible part of the tree always is expanded. Sounds like quite a task ..

On the other hand, maybe an ui which allows expanding 100k of nodes at once isn't optimal anyway - considering the time it would take the user to browse 100k nodes .. if so, SwingX could lean back and do nothing, happy option :-)

Opinions, ideas, references to existing code or discussions highly welcome!

Thanks
Jeanette

 

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kschaefe
Offline
Joined: 2006-06-08
Points: 0

Jeanette,

As noted elsewhere, chunking could help.  A simple Swing Timer that performs a batch of expansions would be fine.  It need checks for ensuring that the model didn't change or some other interrupt (collapse all, etc.) didn't happen.  A nice wait cursor would help during this period.

We also may be able to speed up the process in several ways:

  1. expandAll calls expandRow.  I think this is a hog (gut feel, no profiling).  We already have access to the model.  Why not access it directly, building our own TreePaths to call into setExpandedState?
  2. Chunking approaches
    1. Batch in order.
    2. Walk outward birectionally from the visible rows.

Karl

kleopatra
Offline
Joined: 2003-06-11
Points: 0

Karl,

all good points :-)

With the feedback from OTN, it looks like this is a bigger task than I thought it would be - so created a feature issue

http://java.net/jira/browse/SWINGX-1467

... and keeping up thinking (and re-learning about tree traversals - which I always hated ;-).

Thanks, Jeanette

 

 

Spinnifex
Offline
Joined: 2011-03-29
Points: 0

Hi,

Unfortunately I got no solution for the problem, but I am interested in a solution ;)

At the moment as I wrote on the threads below I am working on a File-System-Treetable and it is not unusual, that

you got more then 100000 files on a default system.

Regards,

Spinnifex