-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eclipse becomes unresponsive when trying to refresh a viewer with more than 30000 elements on one level #818
Comments
A new interface is introduced which can be implemented with content provider. User can return number of items to display with this interface. A wrapper content provider is also implemented. Also there are snippet example for Tree and Table viewer.
Note: the main goal here is to provide a small extension to viewers / content providers API that would allow every existing viewer implementation (Package / Project Explorer, JUnit, Search view etc) that can have a huge number of elements to deal with that huge number of elements without freezing UI and without lot of internal code rework. As the end result we (Advantest) plan to provide patches for all affected SDK views that we are aware of and where we saw freezes. |
A new interface is introduced which can be implemented with content provider. User can return number of items to display with this interface. A wrapper content provider is also implemented. Also there are snippet example for Tree and Table viewer.
TODO proper commit message See eclipse-platform/eclipse.platform.ui#818
TODO: provide proper commit message Fixes eclipse-platform#818
TODO: provide proper commit message Fixes eclipse-platform#818
TODO proper commit message See eclipse-platform/eclipse.platform.ui#818
TODO: provide proper commit message Fixes eclipse-platform#818
TODO: provide proper commit message Fixes eclipse-platform#818
TODO: provide proper commit message Fixes eclipse-platform#818
TODO: provide proper commit message Fixes eclipse-platform#818
TODO: provide proper commit message Fixes eclipse-platform#818
TODO: provide proper commit message Fixes eclipse-platform#818
TODO: provide proper commit message Fixes eclipse-platform#818
A new API has been introduced in ColumnViewer#setItemsLimit(int newLimit). This will limit the number of items rendered by the viewer per parent with a node called IExpandableNode which will then render next block of limited items on selection. This API is introduced to solve UI freeze caused by Viewer when it tries to render large number of items at a given level. This is backward compatible provided clients LabelProvider and ContentProvider safe for receiving IExpandableNode. A new preference is introduced to configure viewer limit on any clients viewer provided they will configure their viewer using WorkbenchViewerSetupsetupViewer(ColumnViewer viewer). Currently ProjectExplorer, ContentOutline, MarkersView and SearchResultsView has been configured to show limited items. Current default for limited items is 10000 Fixes eclipse-platform#818
A new API has been introduced ColumnViewer#setItemsLimit(int newLimit). This will limit the number of items rendered by the viewer per parent with a node called IExpandableNode which will then render next block of limited items on selection. This API is introduced to solve UI freeze caused by Viewer when it tries to render large number of items at a given level. This is backward compatible provided clients LabelProvider and ContentProvider safe for receiving IExpandableNode. A new preference is introduced to configure viewer limit on any clients viewer provided they will configure their viewer using WorkbenchViewerSetupsetupViewer(ColumnViewer viewer). Currently ProjectExplorer, ContentOutline, MarkersView and SearchResultsView has been configured to show limited items. Current default for limited items is 10000 Fixes eclipse-platform#818
A new API has been introduced ColumnViewer#setItemsLimit(int newLimit). This will limit the number of items rendered by the viewer per parent with a node called IExpandableNode which will then render next block of limited items on selection. This API is introduced to solve UI freeze caused by Viewer when it tries to render large number of items at a given level. This is backward compatible provided clients LabelProvider and ContentProvider safe for receiving IExpandableNode. A new preference is introduced to configure viewer limit on any clients viewer provided they will configure their viewer using WorkbenchViewerSetupsetupViewer(ColumnViewer viewer). Currently ProjectExplorer, ContentOutline, MarkersView and SearchResultsView has been configured to show limited items. Current default for limited items is 10000 Fixes eclipse-platform#818
A new API has been introduced ColumnViewer#setItemsLimit(int newLimit). This will limit the number of items rendered by the viewer per parent with a node called IExpandableNode which will then render next block of limited items on selection. This API is introduced to solve UI freeze caused by Viewer when it tries to render large number of items at a given level. This is backward compatible provided clients LabelProvider and ContentProvider safe for receiving IExpandableNode. A new preference is introduced to configure viewer limit on any clients viewer provided they will configure their viewer using WorkbenchViewerSetupsetupViewer(ColumnViewer viewer). Currently ProjectExplorer, ContentOutline, MarkersView and SearchResultsView has been configured to show limited items. Current default for limited items is 10000 Fixes eclipse-platform#818
New org.eclipse.jface.viewers.ColumnViewer#setItemsLimit(int) API has been introduced. This API will limit the number of direct children rendered per parent by the viewers by introducing an intermediate IExpandableNode element which will then render a subset of original children and show more elements on demand (user click). This API is introduced to solve UI freezes caused by viewers when they try to render large number of items at a given level. The changes made for the new API should not affect any existing clients, because new behavior has to be explicitly enabled by using new ColumnViewer.setItemsLimit(int) API. For the clients using this new API the change should be mostly backwards compatible. Clients might need to adopt label provider and viewer code to make them safe for receiving IExpandableNode from viewer. Note: clients that extended (not allowed to be extended) TreeViewer should make sure that isExpandable() returns "false" for IExpandableNode. A new workbench preference is introduced to provide a default viewer limit suitable for most of the clients. Current default value for this limit is 10000. Clients that adopt new API can use this preference to configure their viewer by using new WorkbenchViewerSetup.setupViewer(ColumnViewer) API. Project Explorer, Outline, Markers, Problems and Search views has been adopted to the new API and use the new preference to show limited number of items. Package Explorer adoption for JDT follows in a separated commit. Fixes eclipse-platform#818
New org.eclipse.jface.viewers.ColumnViewer#setItemsLimit(int) API has been introduced. This API will limit the number of direct children rendered per parent by the viewers by introducing an intermediate IExpandableNode element which will then render a subset of original children and show more elements on demand (user click). This API is introduced to solve UI freezes caused by viewers when they try to render large number of items at a given level. The changes made for the new API should not affect any existing clients, because new behavior has to be explicitly enabled by using new ColumnViewer.setItemsLimit(int) API. For the clients using this new API the change should be mostly backwards compatible. Clients might need to adopt label provider and viewer code to make them safe for receiving IExpandableNode from viewer. Note: clients that extended (not allowed to be extended) TreeViewer should make sure that isExpandable() returns "false" for IExpandableNode. A new workbench preference is introduced to provide a default viewer limit suitable for most of the clients. Current default value for this limit is 10000. Clients that adopt new API can use this preference to configure their viewer by using new WorkbenchViewerSetup.setupViewer(ColumnViewer) API. Project Explorer, Outline, Markers, Problems and Search views has been adopted to the new API and use the new preference to show limited number of items. Package Explorer adoption for JDT follows in a separated commit. Fixes eclipse-platform#818
New org.eclipse.jface.viewers.ColumnViewer#setItemsLimit(int) API has been introduced. This API will limit the number of direct children rendered per parent by the viewers by introducing an intermediate IExpandableNode element which will then render a subset of original children and show more elements on demand (user click). This API is introduced to solve UI freezes caused by viewers when they try to render large number of items at a given level. The changes made for the new API should not affect any existing clients, because new behavior has to be explicitly enabled by using new ColumnViewer.setItemsLimit(int) API. For the clients using this new API the change should be mostly backwards compatible. Clients might need to adopt label provider and viewer code to make them safe for receiving IExpandableNode from viewer. Note: clients that extended (not allowed to be extended) TreeViewer should make sure that isExpandable() returns "false" for IExpandableNode. A new workbench preference is introduced to provide a default viewer limit suitable for most of the clients. Current default value for this limit is 10000. Clients that adopt new API can use this preference to configure their viewer by using new WorkbenchViewerSetup.setupViewer(ColumnViewer) API. Project Explorer, Outline, Markers, Problems and Search views has been adopted to the new API and use the new preference to show limited number of items. Package Explorer adoption for JDT follows in a separated commit. Fixes eclipse-platform#818
- reduced new API methods - fixed javadoc - renamed getVisibleLimitBasedChildren to getChildrenWithLimitApplied - improved getChildrenWithLimitApplied implementation Fixes eclipse-platform#818
New org.eclipse.jface.viewers.ColumnViewer#setItemsLimit(int) API has been introduced. This API will limit the number of direct children rendered per parent by the viewers by introducing an intermediate IExpandableNode element which will then render a subset of original children and show more elements on demand (user click). This API is introduced to solve UI freezes caused by viewers when they try to render large number of items at a given level. The changes made for the new API should not affect any existing clients, because new behavior has to be explicitly enabled by using new ColumnViewer.setItemsLimit(int) API. For the clients using this new API the change should be mostly backwards compatible. Clients might need to adopt label provider and viewer code to make them safe for receiving IExpandableNode from viewer. Note: clients that extended (not allowed to be extended) TreeViewer should make sure that isExpandable() returns "false" for IExpandableNode. A new workbench preference is introduced to provide a default viewer limit suitable for most of the clients. Current default value for this limit is 10000. Clients that adopt new API can use this preference to configure their viewer by using new WorkbenchViewerSetup.setupViewer(ColumnViewer) API. Project Explorer, Outline, Markers, Problems and Search views has been adopted to the new API and use the new preference to show limited number of items. Package Explorer adoption for JDT follows in a separated commit. Fixes eclipse-platform#818
- reduced new API methods - fixed javadoc - renamed getVisibleLimitBasedChildren to getChildrenWithLimitApplied - improved getChildrenWithLimitApplied implementation Fixes eclipse-platform#818
- Requires Eclipse 4.29 - See eclipse-platform/eclipse.platform.ui#818 - See eclipse-platform/eclipse.platform.ui@ee92e3d - See eclipse-platform/eclipse.platform.ui#810
Sure, we can set the preference to zero to disable the feature for M3 nd mark API as provisional. |
ok. i will work on it. |
As we have observed some issues with limit. We will revert until we fix the issues. See eclipse-platform#818
As we have observed some issues with limit. We will revert until we fix the issues. See #818
Update: so far all known bugs were fixed and by default feature will be not enabled in M3 (preference need to be manually changed by used to enable the feature). We (Advantest) will continue working on enabling this feature in 4.29 and on implementing reported enhancement requests. Everyone is welcome to help of course :-) |
Thank-you everyone involved for your work and for listening to the community. :-) |
It will calculate the location of expandable node, once it enters visible area of Viewer expand it. see eclipse-platform#818
Adopt Package Explorer, Outline view contribution and editor breadcrumb for Java editor to use new JFace API that allows viewers display huge number of elements without freezing UI. See eclipse-platform/eclipse.platform.ui#818 and eclipse-platform/eclipse.platform.ui#810. Fixes eclipse-jdt#631
Adopt Package Explorer, Outline view contribution and editor breadcrumb for Java editor to use new JFace API that allows viewers display huge number of elements without freezing UI. See eclipse-platform/eclipse.platform.ui#818 and eclipse-platform/eclipse.platform.ui#810. Fixes eclipse-jdt#631
It will calculate the location of expandable node, once it enters visible area of Viewer expand it. see eclipse-platform#818
It will calculate the location of expandable node, once it enters visible area of Viewer expand it. Install resize listener for control when limit is set and remove limit is reset.Do the same thing for Vertical Scroll bar control. see eclipse-platform#818
It will calculate the location of expandable node, once it enters visible area of Viewer expand it. Install resize listener for control when limit is set and remove limit is reset.Do the same thing for Vertical Scroll bar control. Honor the entire drag event as one selection at the end of the drag. see eclipse-platform#818
- Requires Eclipse 4.29 or greater - See eclipse-platform/eclipse.platform.ui#818 - See eclipse-platform/eclipse.platform.ui@ee92e3d - See eclipse-platform/eclipse.platform.ui#810
- Requires Eclipse 4.29 or greater - See eclipse-platform/eclipse.platform.ui#818 - See eclipse-platform/eclipse.platform.ui@ee92e3d - See eclipse-platform/eclipse.platform.ui#810
- Requires Eclipse 4.29 or greater - See eclipse-platform/eclipse.platform.ui#818 - See eclipse-platform/eclipse.platform.ui@ee92e3d - See eclipse-platform/eclipse.platform.ui#810
Could you also add it to the N&N of 4.29 / 4.30 and describe how to enable it in the preferences? Otherwise it is impossible for users to find out of this new feature. |
Ping for N&N entry. Without this entry it is almost for other projects to leverage this improvement in their viewers. |
If I create a new project with 30 000 and open it in the project explorer it still freezes for a very long time. Here is my test handler to generate example project.
|
See #1425, the feature was disabled by default. |
N&N for 4.31 were added via eclipse-platform/www.eclipse.org-eclipse#104 . |
Description:
When we have a large number of files inside a folder in an eclipse workspace refreshing the folder makes the UI freeze.
Large number may depend on machine configuration. As per my test if we have ~30000 files generated on the disk and if we try to refresh the folder under project eclipse freezes. It takes more than 30 seconds to populate tree items in the Package Explorer.
The reason behind this is viewer takes all the time to create Items.
Solution proposed: We will limit the number of Items created and add an Expandable Node. This Expandable Node on click populate next block of Limited elements with another Expandable Node. This way we can keep the Package Explorer responsive.
The goal is to minimize the effort client need to use this solution. So client can implement ILimitBasedContentProvider with the existing content provider and tell us the number items to show in the viewer. WrapperContentProvider is an example and can be used to wrap existing Content Provider.
Below is the screenshot how does it look if we have items limit = 10 and number of files on the file system is 30000.
![partition-based-pe2](https://private-user-images.githubusercontent.com/10301131/245164330-e1c8b14c-99bc-4486-b839-29d5743a21b2.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTkyNTk0MzEsIm5iZiI6MTcxOTI1OTEzMSwicGF0aCI6Ii8xMDMwMTEzMS8yNDUxNjQzMzAtZTFjOGIxNGMtOTliYy00NDg2LWI4MzktMjlkNTc0M2EyMWIyLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA2MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNjI0VDE5NTg1MVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWE4OGZiNzYwZTMxNTc3MDhkNGJhNTg5NzIxMzM1NzkwOTFmODI3YjU3Yjg2MTZjYzA2NDc4OWRmMDE4NDE0NjkmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.9SNE7UoXbshtxstJMTmLwsmVzPObOngSNbyrV49-Z4Q)
The text was updated successfully, but these errors were encountered: