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/
|
|
|
|
Powered by
FUDForum. Page generated in 0.04805 seconds