Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] got a performance question
Well it is more that I am disgusted with how expensive it is to transfer content over from BufferedImage to Image.

The BufferedImage Raster allows access to the bytes as shown in the code example, but ready the javadocs that is a copy. Which we currently then copy again into the correct shape for SWT ImageData.

I was able to ensure that the initial copy provided by BufferedImage can be used as is by SWT ImageData, but am stuck filling in the "alpha" data so it is displayed correctly.

BufferedImage is very complete allowing us to mix RGB and Alpha into the same "raster" of bytes (or ints). 

SWT ImageData has a little bit of flexibility about the structure of ImageData.data (yay) but maintains a separate ImageData.alphaData - and that is where I am a bit stuck.

But yeah I think we can do something here, but I am not sure if it is worthwhile.

Aside: Since we are having to copy bytes over anyways I gave some thought to doing a single pass through the pixels, and doing the logic of merging the layers on a pixel by pixels basis. But really I would like to draw into independent rasters and have the operating system handle this "merge" efficiently. I just cannot figure out how.

-- 
Jody Garnett

On Friday, 15 March 2013 at 7:51 PM, andrea antonello wrote:

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 -

(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…
-

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.
--
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)
_______________________________________________
User-friendly Desktop Internet GIS (uDig)

Back to the top