Community
Participate
Working Groups
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).
Created attachment 195726 [details] Screenshot
See the testbed in bug 310387 comment 9 and the screenshot in the next comment.
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).
Markus, should this problem be fixed for 3.7 ?
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.
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.
Created attachment 195887 [details] Patch This is not the real fix (just hack) but shows how the problem could be fixed.
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.
