Community
Participate
Working Groups
One of the limitations of the current virtual story is that if a user scrolls enough they can populate a table (or tree now) entirely and effectively make it non-virtual. As JFace tries to use SWT state as much as possible we can't delete these items ourselves or we lose information (specifically the selection and checked state). We should decide between us how to go forward. I think we hae two choices 1) JFace introduces some caching support for deleted virtual items 2) SWT comes up with a Table and TreeItem that still answers the API but does not take any system resources. My preference is (2 as it keeps the JFace/SWT split that we have always used and adds functionality for people who do not want to use our viewers but want to use the VIRTUAL support.
Do we actually have a benchmark or a real problem here? I agree that if the user touches all 1,000,000 items, then that's a problem but is this likely?
1000000 items is not as unusual as you think (database results have this all of the time) . I don't have a threshold worked out - we could write a performance suite and then choose a number from there. The threshold would have to take space and time into consideration of course.
>I agree that if the user touches all 1,000,000 items, then that's a problem >but is this likely? NOTE: The user must touch all 1,000,000 items for them to be created. For example, he needs to sit there for however long it takes, holding the down arrow key until every item is visited. At that point, all the items will have been touched and created. Until someone has a scenario that shows a real problem, I hesitate to fix this. Tod?
I agree with you Steve. I think this is low priority and not worth the overhead it would create. If we ever do this I think this is something JFace not SWT would provide.
Actually, I was thinking that SWT would provide it so that memory use could be as minimal as possible. However, it's low priority for now.
We are using virtual tables with RAP for our serverside applications. Our applications run in multi-user mode. Therefore the number of lines actually visited by each individual user does not have to be that large to cause problems. So in our case reducing the memory footprint of the tables is a real concern.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
