Community
Participate
Working Groups
Regarding the VIRTUAL Tree usage of a TreeViewer: As you know, even with a VIRTUAL table the setItemCount() function does not take a constant or near-constant amount of time to process in some platforms. It particular, in Windows it is costly to do a setItemCount with a big number (upwards from 10000), even if those items are not visible, such as when being children of a collapsed parent. My optimization suggestion is the following: Whenever you have a collapsed parent item with a big number of children, instead of setting the item count of that parent to the real number of children, you just set it to 1 (it's 1 instead of 0 so that the expand toggle appears). Then, you add an expand event listener, and whenever said parent is expanded, you set the item count to the correct number. It seems to me it is perfectly legal to change the item count in this way, at least with a regular Tree. Performance-wise it does make a lot of difference when you have a tree with several tree items which are collapsed but have a large number of children. So, is this optimization valid?
According to Carolyn on the SWT-Newsgroup the setItemCount(1) is legal so we should investigate Boris
Remenber that getItemCount() should return the count to be set, not 1. Even, you can read individual children programatically, even though the parent is collapsed. Just to remember that...
The idea makes sense. http://wiki.eclipse.org/Platform_UI/How_to_Contribute
@Viliam Durina Yes, getItemCount() would not return the correct amount to be set, but I think such queries should be made to the model and not to the UI components. And the JFace viewers already promote such separation.
Hitesh is now responsible for watching bugs in the [Viewers] component area.
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. If you have further information on the current state of the bug, please add it. 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.
