Eclipse Community Forums: Standard Widget Toolkit (SWT) » new Image(ImageData) can never be "fast" on Kepler/Linux64/Gtk ?

Home » Eclipse Projects » Standard Widget Toolkit (SWT) » new Image(ImageData) can never be "fast" on Kepler/Linux64/Gtk ?(A processing path marked as "fast" in the source code is never executed)

Show: Today's Messages :: Show Polls :: Message Navigator

new Image(ImageData) can never be "fast" on Kepler/Linux64/Gtk ? [message #1061108]

Thu, 30 May 2013 04:55

Diego Tognola

Messages: 14
Registered: July 2009

Junior Member

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" ?

*On Kepler, Linux 64bit, org.eclipse.swt.gtk.linux.x86_64.source_3.102.0.v20130501-2152.jar

[Updated on: Thu, 30 May 2013 06:24]

Report message to a moderator

Re: new Image(ImageData) can never be "fast" on Kepler/Linux64/Gtk ? [message #1062996 is a reply to message #1061108]

Tue, 11 June 2013 16:34

Grant Gayed

Messages: 2150
Registered: July 2009

Senior Member

Link to mailing list discussion of this:
http://dev.eclipse.org/mhonarc/lists/platform-swt-dev/msg07533.html .

On 5/30/2013 12:55 AM, Diego Tognola wrote:
> Hi all,
>
> Although coded for "fast" processing of new Image(Device, ImageData) it
> appears that at least on Kepler&Linux this path is never taken and the
> Image creation happens via the processing path labelled "comprehensive"
> in the source.
>
> 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" ?
>
> *On Kepler, Linux 64bit,
> org.eclipse.swt.gtk.linux.x86_64.source_3.102.0.v20130501-2152.jar

Report message to a moderator