Eclipse Community Forums: Standard Widget Toolkit (SWT)

Help

Home

Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Is this a bug?

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

Is this a bug? [message #528573]

Wed, 21 April 2010 06:35

Eclipse User

Originally posted by: totolaricot.mac.com

I was writting a dedicated Image32 class for dealing exclusively with
ARGB with transparency and noticed the following in the win32 version
Image.java:

void initNative(String filename) {
....
int /*long*/ bitmap = Gdip.Bitmap_new(chars, false);
....
switch (pixelFormat) {
case Gdip.PixelFormat16bppRGB555:
case Gdip.PixelFormat16bppRGB565:
this.handle = createDIB(width, height, 16);
break;
case Gdip.PixelFormat24bppRGB:
this.handle = createDIB(width, height, 24);
break;
case Gdip.PixelFormat32bppRGB:
// These will loose either precision or
transparency
case Gdip.PixelFormat16bppGrayScale:
case Gdip.PixelFormat48bppRGB:
case Gdip.PixelFormat32bppPARGB:
case Gdip.PixelFormat64bppARGB:
case Gdip.PixelFormat64bppPARGB:
this.handle = createDIB(width, height, 32);
break;
}
if (this.handle != 0) {
transfer the data via Graphics_DrawImage()
} else {
transfer the data via LockBits()/new ImageData()/manual creation of DIB
}

The switch statement does not include *Gdip.PixelFormat32bppARGB* even
though this format is supported by GDI+. The result is that even though
bitmat was properly loaded, and a DIB section can be used to transfer
the bits via a blit, the code goes through the manual
LockBits()/ImageData generation path. I know that you regularly find
issues between 32/64 platforms, and was wondering if this is to address
one (maybe it would make sense to add a comment to the switch/case
mentioning it), or if it is just an omission and we can safely add that
to the switch:
case Gdip.PixelFormat32bppARGB:

cheers
LM/

Report message to a moderator

Re: Is this a bug? - ARGB bitmaps [message #528591 is a reply to message #528573]

Wed, 21 April 2010 08:21

L. Mihalkovic

Messages: 6
Registered: July 2009

Junior Member

I saw that the PixelFormat32bppARGB format is handled 'manually' so that you separately initialize the ImageData.alphaData. I do not have access to a 64 bit version of XP/2003, so in your experience do you know of any reasons to not be able to rely on your Graphics_DrawImage() fast track to transfer the data into the DIB section on these platforms? (It works fine on my test XP box)

Also, I have a choice of storing the image as the DIB section, or directly keep the Gdip.Bitmap_new result (I saw your comment inside GC about caching the GDI+ Bitmap). Would you be able to share some advise on pros/cons?

PS:
the purpose of these Image32/ImageData32 is to deal with ARGB images without separating the Alpha data as is done in the current ImageData, so that native platform support is better utilized for this type of images than by the universal Image/ImageData. It works like this:

Image32 img32 = new Image32(w, h); // image is transparent
GC gc = new GC(img);
gc.xyz(...);
gc.dispose();

in a paint event for a Canvas I can then do:

GC gc = event.gc;
img32.draw(gc, 0, 0); // draw methods is here so that there is no need to modify GC (Image32 does not extend Image.. should it?)

I made a Cocoa version and the win32 is almost complete. If there is an interest, I would share the code in bugzilla)

Report message to a moderator

Previous Topic:	Composite with Canvases doesn't scroll
Next Topic:	Caret in StyledText won't hide

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 23 06:56:31 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter