Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Is this a bug?
Is this a bug? [message #528573] Wed, 21 April 2010 06:35 Go to next message
Eclipse UserFriend
Originally posted by:

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

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);
case Gdip.PixelFormat24bppRGB:
this.handle = createDIB(width, height, 24);
case Gdip.PixelFormat32bppRGB:
// These will loose either precision or
case Gdip.PixelFormat16bppGrayScale:
case Gdip.PixelFormat48bppRGB:
case Gdip.PixelFormat32bppPARGB:
case Gdip.PixelFormat64bppARGB:
case Gdip.PixelFormat64bppPARGB:
this.handle = createDIB(width, height, 32);
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:

Re: Is this a bug? - ARGB bitmaps [message #528591 is a reply to message #528573] Wed, 21 April 2010 08:21 Go to previous message
L. Mihalkovic is currently offline L. MihalkovicFriend
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?

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);;

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)
Previous Topic:Composite with Canvases doesn't scroll
Next Topic:Caret in StyledText won't hide
Goto Forum:

Current Time: Tue Jan 19 13:25:56 GMT 2021

Powered by FUDForum. Page generated in 0.01819 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top