Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 345910

Summary: Image(Device, Image, int) doesn't correctly copy transparent pixels on Windows 7
Product: [Eclipse Project] Platform Reporter: Markus Keller <markus.kell.r>
Component: SWTAssignee: Platform-SWT-Inbox <platform-swt-inbox>
Status: CLOSED WONTFIX QA Contact: Felipe Heidrich <eclipse.felipe>
Severity: normal    
Priority: P3 CC: daniel_megert, eclipse.felipe, remy.suen
Version: 3.7   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard: stalebug
Attachments:
Description Flags
Problematic image
none
Screenshot
none
Patch none

Description Markus Keller CLA 2011-05-16 06:38:39 EDT 
Created attachment 195713 [details]
Problematic image

I20110512-2000

The Image(Device, Image, int) constructor doesn't correctly copy transparent pixels on Windows 7 in certain images. Looks good on Windows XP, GTK, and Cocoa.

As a workaround for the Cocoa bug 310387, we've added
     copy= new Image(image.getDevice(), image, SWT.IMAGE_COPY);
in AnnotationsConfigurationBlock#getImage(AnnotationPreference) (bug 345180).

But now, the "Search Results" icon on the Annotations preference page is rendered without transparency on Windows 7 (white background when the table item is selected).

When I replace that line with
     return image;
, then it looks good again, which shows that the bug is really in the copy constructor.

The problem with this specific image seems to be that the transparent color (index 15) has the same value (255,255,255) as another color (index 14).
Comment 1 Markus Keller CLA 2011-05-16 08:52:31 EDT 
Created attachment 195726 [details]
Screenshot
Comment 2 Markus Keller CLA 2011-05-16 11:26:53 EDT 
See the testbed in bug 310387 comment 9 and the screenshot in the next comment.
Comment 3 Markus Keller CLA 2011-05-17 06:08:30 EDT 
We released a better fix for bug 345180 to HEAD of AnnotationsConfigurationBlock, so this problem does not appear any more on the preferences page.

But this bug is still visible in the testbed when

    new Image(image.getDevice(), image, SWT.IMAGE_COPY)

is called on the problematic image (no matter how the image is read from disk).
Comment 4 Felipe Heidrich CLA 2011-05-17 11:18:49 EDT 
Markus, should this problem be fixed for 3.7 ?
Comment 5 Markus Keller CLA 2011-05-17 11:29:51 EDT 
We currently don't need the fix, so if you don't think it's a regression (I didn't test 3.6), then I'm OK with deferring.
Comment 6 Felipe Heidrich CLA 2011-05-17 12:01:10 EDT 
This is what is happening in Windows.
When the image has an indexed palette, and the depth is 4 (? didn't happen when depth==8), the BitBlt() operation will use for image data the lowest index in the palette that has the same RGB value as the transparent pixel.

For example, if the transparent pixel in the source image is 5 and the RBG in the palette for 5 and 4 is 255,255,255, after the OS.BitBlt() the value in the new image data for transparent x,y location will be 4 not 5.
Comment 7 Felipe Heidrich CLA 2011-05-17 12:02:55 EDT 
Created attachment 195887 [details]
Patch

This is not the real fix (just hack) but shows how the problem could be fixed.
Comment 8 Eclipse Genie CLA 2019-10-16 19:57:20 EDT 
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.