I think your conclusions are correct.

SWT ImageData is always MSB and Cairo surfaces have platform endianness (LSB on x86_64), so SWT needs to do the conversion of the bytes in order to properly create a cairo surface.

Note that this is not the case for the !OS.USE_CAIRO code path.  Pixbufs are always MSB independent of the platform endianness.

This is not a bug.   It is just the necessary code to create an image.   The only way to avoid this conversion is if ImageData was changed to support LSB and MSB formats.   This would require changes in the SWT image loaders so that they would load ImageData in the appropriate format for the platform. This is a non trivial amount of work.

Do you have numbers to determine how performance is affected?

Finally, we would be glade to provide assistance to anyone in the community if one wishes to improve the ImageData support.

Silenio



From:        Josef Pixsie <dev.pixsie.mobi@xxxxxxxxx>
To:        platform-swt-dev@xxxxxxxxxxx,
Date:        06/06/2013 10:21 AM
Subject:        [platform-swt-dev] new Image(ImageData) can never be "fast" on        Kepler/Linux64/Gtk ?
Sent by:        platform-swt-dev-bounces@xxxxxxxxxxx

---

Hi all,

Although there is a path marked as "fast" in the code related to new
Image(Device, ImageData), it appears that at least on
Kepler/Linux64/Gtk this path is never taken and the Image creation
happens via the processing path labelled "comprehensive".

Does this mean that image creation on Kepler/Linux64/Gtk is slower
than on other platforms ? Is this intended or a bug ?

Not surprisingly I arrived at this point while debugging the
performance behaviour of image creation...


Here's my line of deduction*:

1) From see org.eclipse.swt.graphics.Image.init(org.eclipse.swt.graphics.ImageData)
it follows that:
1a) For not OS.BIG_ENDIAN, the destOrder is always LSB_FIRST
1b) The destDepth is hardcoded =32
==> dtype is always TYPE_GENERIC_32_LSB in
org.eclipse.swt.graphics.ImageData.blit(int, byte[], int, int, int,
int, int, int, int, int, int, int, int, byte[], int, int, int, byte[],
int, int, int, int, int, int, int, int, int, int, boolean, boolean)

2) From org.eclipse.swt.graphics.ImageData.getByteOrder() is follows that:
srcOder is always LSB_FIRST for 16bit depth and MSB_FIRST for 24/32 bit depth

3) From (2) and org.eclipse.swt.graphics.ImageData.blit(int, byte[],
int, int, int, int, int, int, int, int, int, int, int, byte[], int,
int, int, byte[], int, int, int, int, int, int, int, int, int, int,
boolean, boolean) it follows that:
==> stype is never TYPE_GENERIC_32_LSB

Consequently stype != dtype and dtype != TYPE_GENERIC_32_MSB (on my
platform) and therefore ImageData.blit will always take the route with
comment "Comprehensive blit (apply transformations)".

Now without further looking at this I suspect that the comprehensive
blit is significantly slower compared to what is labelled "fast" ?

Any feedback appreciated,
Diego


*On Kepler, Linux 64bit,
org.eclipse.swt.gtk.linux.x86_64.source_3.102.0.v20130501-2152.jar
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev



_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev