Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Inefficient image loadings?
|
Re: Inefficient image loadings? [message #454224 is a reply to message #454222] |
Tue, 19 April 2005 13:01 |
Eclipse User |
|
|
|
Originally posted by: Paul.Helster.gmail.com
Daniel Krügler wrote:
> Hello SWT programmers,
>
> I observed that simple SWT image loadings of JPG's (I didn't test other
> formats to discuss about) seem to have observable performance lacks.
I wrote a plugin that reads, transforms, and writes many JPGs. At first,
I was using SWT images with poor results too. I now use
javax.imageio.ImageIO from within my SWT-based plugin and it has
substantially improved performance.
Paul
>
> E.g. a ~110kB image (1602 x 1200 Pixels, 24 BitsPerPixel) needs about
> 3-4 secs on my Win2K system (AMD 1800 Dual Athlon), while other image
> programs (even our old C++ program) need far less than a second.
>
> To verify whether this was due to my possibly own deficient programming
> style I checked the same image with the ImageViewer example found in the
> article
>
> http://www.eclipse.org/articles/Article-Image-Viewer/Image_v iewer.html
>
> where I observed roughly the same overhead (maybe 0.5 secs less per
> image). Note that time overhead results simply due to a single line, like
>
> Image image = new Image(display,
> " C:/eclipse/eclipse/plugins/org.eclipse.platform_2.0.2/eclips e_lg.gif ");
>
> The time overhead cannot be due to file access (obvious for everyone, I
> assume), but I also checked that using alternative code like
>
> final byte[] data = ..; // Get image data
> final InputStream is = new ByteArrayInputStream(data);
> try {
> final ImageData imgData = new ImageData(is); // bottle neck!!
> final ImageDescriptor d = ImageDescriptor.createFromImageData(imgData);
> fMyImage = d.createImage(true);
> } finally {
> is.close();
> }
>
> which didn't do better (Note: This last use case is actually more
> important for me than a file-based access because our program accesses
> its images from a data base and thus they are already in memory).
>
> Does anyone know what the reasons are for those performance lacks and
> more important: How to fix them?
>
> This is a very severe problem for us and it became obvious during our
> process going from our previous browser-based C++ program to an Eclipse
> RCP program. Note also that (at least until now) we have not seen any
> other performance problems during that change.
>
> Thank you very much for any input,
>
> Daniel Krügler
>
|
|
|
Re: Inefficient image loadings? [message #454230 is a reply to message #454224] |
Tue, 19 April 2005 14:03 |
Daniel Krügler Messages: 853 Registered: July 2009 |
Senior Member |
|
|
Hello Paul Lester,
Paul Helster schrieb:
> I wrote a plugin that reads, transforms, and writes many JPGs. At first,
> I was using SWT images with poor results too. I now use
> javax.imageio.ImageIO from within my SWT-based plugin and it has
> substantially improved performance.
Thanks for your answer! If I correctly understand your approach, you
effectively use AWT for images, i.e. java.awt.image.BufferedImage??
That is quite interesting (and shocking) to me, because my understanding
was, that one of the corner reasons for using SWT versus AWT is to
expect performance **wins** - not lacks - due to delegation to
system-specific techniques to get the wished GU effects.
It would be nice, if others could also add their experience - I still
hope that I just did not use the correct SWT way to present images.
Thanks and Greetings from Bremen,
Daniel Krügler
|
|
|
Re: Inefficient image loadings? [message #454232 is a reply to message #454230] |
Tue, 19 April 2005 14:50 |
Eclipse User |
|
|
|
Originally posted by: Paul.Helster.gmail.com
Daniel Krügler wrote:
> Hello Paul Lester,
>
> Paul Helster schrieb:
>
>> I wrote a plugin that reads, transforms, and writes many JPGs. At
>> first, I was using SWT images with poor results too. I now use
>> javax.imageio.ImageIO from within my SWT-based plugin and it has
>> substantially improved performance.
>
>
> Thanks for your answer! If I correctly understand your approach, you
> effectively use AWT for images, i.e. java.awt.image.BufferedImage??
Yes, indeed, I use BufferedImage, among other things. To give you an
idea, here is my import list for a Class I named ImageProxy that does
alot of the image work:
import java.awt.RenderingHints;
import java.awt.geom.AffineTransform;
import java.awt.image.AffineTransformOp;
import java.awt.image.BufferedImage;
import java.io.BufferedInputStream;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.HashMap;
import java.util.Map;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.imageio.ImageIO;
import javax.imageio.stream.MemoryCacheImageOutputStream;
import org.eclipse.swt.graphics.Image;
import org.eclipse.swt.graphics.ImageData;
import org.eclipse.swt.graphics.ImageLoader;
import org.eclipse.swt.widgets.Display;
>
> That is quite interesting (and shocking) to me, because my understanding
> was, that one of the corner reasons for using SWT versus AWT is to
> expect performance **wins** - not lacks - due to delegation to
> system-specific techniques to get the wished GU effects.
>
> It would be nice, if others could also add their experience - I still
> hope that I just did not use the correct SWT way to present images.
>
> Thanks and Greetings from Bremen,
>
> Daniel Krügler
>
>
>
>
|
|
| |
Re: Inefficient image loadings? [message #454284 is a reply to message #454230] |
Tue, 19 April 2005 15:55 |
Eclipse User |
|
|
|
Originally posted by: Paul.Helster.gmail.com
Here is a piece of code you can try out to test performance:
BufferedImage image2 = ... // obtain a BufferedImage
ByteArrayOutputStream temp = new ByteArrayOutputStream();
MemoryCacheImageOutputStream o =
new MemoryCacheImageOutputStream(temp);
ImageIO.write(image2, "jpg", o);
ImageData imageData = new ImageData(
new ByteArrayInputStream(temp.toByteArray()));
At this point, you have an Eclipse ImageData you can use.
Paul Helster wrote:
> Daniel Krügler wrote:
>
>> Hello Paul Lester,
>>
>> Paul Helster schrieb:
>>
>>> I wrote a plugin that reads, transforms, and writes many JPGs. At
>>> first, I was using SWT images with poor results too. I now use
>>> javax.imageio.ImageIO from within my SWT-based plugin and it has
>>> substantially improved performance.
>>
>>
>>
>> Thanks for your answer! If I correctly understand your approach, you
>> effectively use AWT for images, i.e. java.awt.image.BufferedImage??
>
>
> Yes, indeed, I use BufferedImage, among other things. To give you an
> idea, here is my import list for a Class I named ImageProxy that does
> alot of the image work:
>
> import java.awt.RenderingHints;
> import java.awt.geom.AffineTransform;
> import java.awt.image.AffineTransformOp;
> import java.awt.image.BufferedImage;
> import java.io.BufferedInputStream;
> import java.io.ByteArrayInputStream;
> import java.io.ByteArrayOutputStream;
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.IOException;
> import java.io.InputStream;
> import java.util.HashMap;
> import java.util.Map;
> import java.util.logging.Level;
> import java.util.logging.Logger;
>
> import javax.imageio.ImageIO;
> import javax.imageio.stream.MemoryCacheImageOutputStream;
>
> import org.eclipse.swt.graphics.Image;
> import org.eclipse.swt.graphics.ImageData;
> import org.eclipse.swt.graphics.ImageLoader;
> import org.eclipse.swt.widgets.Display;
>
>>
>> That is quite interesting (and shocking) to me, because my
>> understanding was, that one of the corner reasons for using SWT versus
>> AWT is to
>> expect performance **wins** - not lacks - due to delegation to
>> system-specific techniques to get the wished GU effects.
>>
>> It would be nice, if others could also add their experience - I still
>> hope that I just did not use the correct SWT way to present images.
>>
>> Thanks and Greetings from Bremen,
>>
>> Daniel Krügler
>>
>>
>>
>>
>
>
|
|
| | |
Re: Inefficient image loadings? [message #454326 is a reply to message #454316] |
Wed, 20 April 2005 13:08 |
Eclipse User |
|
|
|
Originally posted by: Paul.Helster.gmail.com
Daniel, you have a good point and I have no answer. It has been a while
since I implemented this plugin and my findings were not documented.
All I remember is that I have performance problems using SWT images. I
tried various approaches to increase performance and ended up using
imageIO and AWT for transformations (scale, rotations etc.) because it
was the fastest (well, I tried something else too - jmagick - but the
improvement it brought was minimal when balanced with the complexity it
brought.)
So maybe my suggestion is not addressing your concern. But I use imageIO
in a plugin that loads photos in an album-like editor. It generates
thumbnails, and offers rotations, and eventually more image manipulation
actions. Loading 3megs images in this album, and generating thumbnails
does not have any performance problems with this approach.
Paul
Daniel Krügler wrote:
> Hello Paul Lester,
>
> I just have to jump into again:
>
> Paul Helster schrieb:
>
>>
>> Here is a piece of code you can try out to test performance:
>>
>> BufferedImage image2 = ... // obtain a BufferedImage
>>
>> ByteArrayOutputStream temp = new ByteArrayOutputStream();
>> MemoryCacheImageOutputStream o =
>> new MemoryCacheImageOutputStream(temp);
>> ImageIO.write(image2, "jpg", o);
>> ImageData imageData = new ImageData(
>> new ByteArrayInputStream(temp.toByteArray()));
>>
>> At this point, you have an Eclipse ImageData you can use.
>
>
> I am wondering concerning the advantages of your approach versus that
> of mine. Let me recapitulate here:
>
> final byte[] data = ..; // Get image data
> final InputStream is = new ByteArrayInputStream(data);
> try {
> final ImageData imgData = new ImageData(is); // bottle neck!!
> final ImageDescriptor d = ImageDescriptor.createFromImageData(imgData);
> fMyImage = d.createImage(true);
> } finally {
> is.close();
> }
>
> Please notice, that the line marked with "bottle neck!!" is actually the
> point of the observed performance gap. Now comparing to your code, I see
>
> ImageData imageData = new ImageData(
> new ByteArrayInputStream(temp.toByteArray()));
>
> which seems (at least to my opinion) to take the same route.
>
> Which advantages does the "detour" via BufferedImage and ImageIO.write
> have if my image is already in memory (see the line "Get image data",
> which has shown **not** to be the reason of the bottle neck)???
>
> Thanks for your patience,
>
> Daniel
>
|
|
| | | |
Goto Forum:
Current Time: Thu Apr 25 17:37:22 GMT 2024
Powered by FUDForum. Page generated in 0.04149 seconds
|