[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] got a performance question
|
Well I kind of answered my question .. what all our example optimisations have in common is lack of transparency.
Our fallback solution is similar to this snippet - http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet156.java
(With our solution copying three bytes over, and the above working an int at a time).
I also found the following interesting example which could result in a speedup…
- http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet341.java
The example is taking a buffer provided by OpenGL and setting it up for use as an ImageData.
The interesting part is that this is a 32 bit depth buffer (i.e. using alpha data like we want), they manage to use the bytes directly by assigning the following PaletteData:
ImageData data = "" ImageData(bounds.width, bounds.height, 32, new PaletteData(0xFF000000, 0xFF0000, 0xFF00), PAD, bytes);
We would still require a manual pass to extract the alpha information, but the raw bytes of our buffered image could be used as is .. resulting in a speedup.
On Friday, 15 March 2013 at 12:41 PM, Jody Garnett wrote:
I was reusing the AWTSWTImageUtils class in another project and noticed an inconsistency.
The createBufferedImage method consists of:
/** Create a buffered image that can be be converted to SWTland later */
public static BufferedImage createBufferedImage( int w, int h ) {
//AWTSWTImageUtils.checkAccess();
return new BufferedImage(w, h, BufferedImage.TYPE_4BYTE_ABGR_PRE);
}
But the createImagerData method is optimised for TYPE_3BYTE_BGR.
The consequence of this is that we are using a for loop to copy bytes over from the BufferedImage to an SWT image one at a time. Changing over to BGR did not actually help (the result lacked transparency and came out all black). I had always assumed that this optimisation was intended for windows or linux or something - but in testing today it is not used on Windows either.
So chances are there is some performance left on the ground here we could really use.
Jesse do you remember if it is possible to set up a BufferedImage we can cleanly use for ImageData? Or am I missing the point here.
