Summary: | UI freezes in EditorRegistry.getSystemExternalEditorImageDescriptor | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Michael Keppler <michael.keppler> | ||||||
Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> | ||||||
Status: | NEW --- | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | rolf.theunissen, shashwat.work, twolf | ||||||
Version: | 4.19 | ||||||||
Target Milestone: | --- | ||||||||
Hardware: | PC | ||||||||
OS: | Windows 10 | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Michael Keppler
2020-12-24 11:32:17 EST
Inside org.eclipse.ui.internal.registry.EditorRegistry.getImageDescriptor(String, IContentType) line 1377-1387: // for dynamic UI - comment out the next line // extensionImages.put(key, anImage); Which is the caching you are referring to. This is commented out from the initial contribution of this code, Bug 37668 for Eclipse 3.1. Be sure that we don't loose the 'dynamic UI' (whatever that should be). I wouldn't want to cache the _overall_ icon lookup, but rather just the external icons. So activating an eclipse plugin with an editor for some file extension would still change the result, but installing a Windows application for the same extension outside eclipse would not change the result anymore (for the running eclipse session). Therefore only the result of getSystemExternalEditorImageDescriptor() would be cached. I've been looking into the profiler a bit more closely. The slowness is caused by SWT using the Windows registry information to look for the associated executable, it's document name, and the icon of the application. All the time is spent in OS.AssocQueryString(), which maps directly to a native Windows function. So I guess there is not much to be optimized in that method itself. (see second screenshot). Created attachment 285115 [details]
AssocQueryString consumes all the time
EGit does that already; see org.eclipse.egit.ui.UIUtils.getEditorImage(). The reason is the same: EditorRegistry.getSystemExternalEditorImageDescriptor() is slow at least on Windows and on Linux. See bug 464891. "dynamic UI" probably refers to changes made in the OS-level default editor associations resulting in showing a new icon as soon as possible (on the next refresh?) in Eclipse. Re comment 1: The commenting out of the caching and the dynamic UI comment were added in commit dbe9382347d3b20e300466542572c8892e05fb91 on 2004-01-08 "First cut of adding dynamic UIs to the workbench". No bug linked. [1] https://git.eclipse.org/r/plugins/gitiles/platform/eclipse.platform.ui/+/dbe9382347d3b20e300466542572c8892e05fb91%5E%21/#F17 From old mailing list messages, "dynamic UI" could also refer to being able to load and unload UI bundles dynamically without having to restart Eclipse, and still have a sane and usable UI. See e.g. the thread starting at [1]. If that was the intention: * I don't think not caching icons for external editors was correct; and * has unloading a loaded and activated UI bundle with open views or editors ever worked? [1] https://www.eclipse.org/lists/platform-ui-dev/msg01275.html |