Community
Participate
Working Groups
Build Identifier: 3.5.1 I´m using a tree table with style SWT.VIRTUAL|SWT.MULTI|SWT.FULL_SELECTION with a LazyTreeContentProvider. The Tree contains about 50000 rows. Our application constantly adds and removes rows, which makes a refresh of the tree neccessary. Refreshing the tree together with a simultaneous user interaction like scrolling or page down or row selection makes the UI freeze. I already tried refreshing via: display.(a)syncExec or encapsulated by a Job or UIJob without success. The error seems to happen deep inside SWT´s eventhandling. HandleEvent-methods of the tree are not called. Reproducible: Always Steps to Reproduce: 1.Create TreeViewer SWT.VIRTUAL|SWT.MULTI|SWT.FULL_SELECTION 2.Create LazyTreeContentProvider 3.Create initial list (java.util.List) and set it as input 4.Add about 3 new rows per second to the tree and refresh the tree 5.Make simultaneous user interactions like scrolling or page up/down
For what it's worth, this seems related to bugs 289848 and 259141. It can be reproduced under Eclipse 3.6.2 using the snippet http://wiki.eclipse.org/JFaceSnippets#Snippet047VirtualLazyTreeViewer by just adding SWT.MULTI to the table flags. Without SWT.MULTI (i.e. SWT.SINGLE) it's fast, but with SWT.MULTI it is slow because the mechanism to preserve the multi-element selection is slow.
Created attachment 211148 [details] Snippet to demonstrate problem after refreshing tree This code snippet demonstrates that the tree refresh code is not directly responsible for the code; it executes quickly when you step through the code. Use of SWT.MULTI is not the cause of the problem. Note that the use of SWT.SINGLE for the CheckboxTree also shows the performance hit. It seems that the best diagnosis of the root problem is detailed in Bug 310260 (closed as duplicate of Bug 259141). @Felipe how do we move forward from here.
Note that we just made a change in this area that may help. Please see bug 259141 comment 20 for details.
I do not see a change in behavior when using Attachment 211148 [details] with swt-N20121022-1000-win32-win32-x86 (Windows 7 x64, Java 6u37 x86, SWT 32-bit). The initial tree drawings take ~8 sec and the refreshes take even longer.
Reassigning this bug to JFace. SWT does not have a call to get the checked state of all items in a Tree - only of one TreeItem at a time. I see that there is a method in JFace's CheckboxTreeViewer called gatherState(CustomHashtable checked, CustomHashtable grayed, Widget widget), which goes through every single TreeItem in the entire Tree (virtual or not) in order to collect up the checked state of every possible item in the Tree. This ends up calling CheckboxTreeViewer.updateElement(Object parent, int index) for every item. This should not be done for a virtual Tree. Only items that are visible (i.e. root items or items in expanded branches) need to have their check state updated.
> Only items that are visible (i.e. root items or items in expanded branches) > need to have their check state updated. Actually, does JFace enforce a tri-state (i.e. "checked/unchecked/grayed") on a parent item if some of the child items are checked? If so, then the fix for this is easy: - if an item is grayed, then you need to go through its children and look at their state. - if an item is checked, then you do not need to go through its children because all of them are guaranteed to be checked. - if an item is neither checked nor grayed, then you do not need to go through its children because all of them are guaranteed to be unchecked. So enforcing tri-state would save a lot of recursion. (and it is, I believe, the way that most (all?) checkbox-tree UIs work).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
