Community
Participate
Working Groups
Build ID: I20080207-1530 Steps To Reproduce: FileImageDescriptor currently loads its image data from the file system using the an inputstream. This pulls the image loading code into Java instead of using SWTs higher performance APIs. The FileImageDescriptor code should be changed to use the faster operating system image loading from a file name if possible. new Image(Device, String) for example. In a large RCP product making this change in application code resulted in a 800ms improvement to blitting a large PNG with transparency. More information:
Chris can you give an idea of the code you were using to determine this improvement? It sounds like a good test case to me.
Created attachment 90209 [details] Snippet of comparing ImageDescriptor vs new Image
Tod - I assume a stand-alone RCP example would be prefereable, is that right? In the interest of responding sooner rather than later, I attached the snippet of code I used.
I want to add a test suite for this so I don't even need an RCP app - a JFace performance test is a good start.
Created attachment 90231 [details] Work in Progress Here my current work on one that can support the current API without any changes but it is relying on the FileLocator which currently has Bug 219645 with it. Chris I assume you are using this in an RCP app with OSGi loaded? This is the case where I can most likely use the optimizations from SWT as I will need to file locator to translate URLs.
Fixed to use the SWT ImageData loading in build >20080221. I have written a performance test for this in org.eclipse.ui.tests.performance (FileImageDescriptorTest) but I will need some more complex images to get big enough numbers to see what kind of saving we get from this. Chris can you give me an idea of how to whip up images that would we a lot faster with the new SWT processing for testing?
Reopening - the current solution is not any faster. Currently the solution to load image data with the filename rather than the Stream - Steve would this method take advantage of native loading?
Created attachment 90692 [details] New patch This patch reverts getImageData to the old behaviour but optimized the createImage call. It is about 40% faster in Chris's test case but my suite needs some work to verify.
> Currently the solution to load image data with the filename rather > than the Stream Yes, it should be faster. To be clear, in the end, you will be calling new Image(Device, String) rather than new Image (Device, InputStream), right?
Correct.
New patch released for build >20080227. Chris if you could verify with your local test case I would appreciate it. Note that the released version does not change how ImageData is loaded but overides the ImageData based loading from ImageDescriptor with a direct call to the file based API.
Does this mean that most plug-ins will not benefit from faster loading times, since images are located inside of JARs? What about descriptors created from URLs that are local files?
Not it means calls to getImageData will not be affected. We are no longer using the ImageData to load images from a FileImageDescriptor so you should see improvements both within and external to OSGi. See FileImageDescriptor #getFilePath if you want to see the implementation of the file lookup
We're loading images using: URL url = FileLocator.find(bundle, iconPath, null); imageDescriptor = ImageDescriptor.createFromURL(url); It seems like this wouldn't result in a FileImageDescriptor.
Correct - that is a URLImageDescriptor
verified in I20080325-0100
Hi Tod, could you please provide patch for Eclipse 3.2.2 Jface? Our product is based on Eclipse 3.2.2, we would like to back port this fix to 3.2.2
Created attachment 97070 [details] R 3.3.2 version R3.3.2 version using the R 3.3.2 error reporting
Hi Tod, Is the patch you provide for Release 3.3.2 or 3.2.2? Our product is based on 3.2.2, we would appreciate if you could provide patch for 3.2.2. Thanks!
