Re: [udig-devel] got a performance question

[andrea antonello <andrea.antonello@xxxxxxxxx>]

Hi Jody,
funky stuff you found out :)

Were you able to do a test on this to understand how much we would gain?

Nice,
Andrea



On Fri, Mar 15, 2013 at 3:28 AM, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:
> 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 = new 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.
> --
> Jody Garnett
>
> 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.
>
>
> --
> Jody Garnett
>
>
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>