Community
Participate
Working Groups
Created attachment 119077 [details] Win ICO file Set the attached Win ICO image to a treeitem and notice this: - 3.3.x looks fine anti-aliased - 3.4.1 looks aliased - 3.5.x looks fine anti-aliased Please consider for 3.4.2
We aren't going to make it for 3.4.2 now. Sorry.
I digged more into this issue and got some insight. This problem does not seem to be caused by using different SWT versions (I was able to reproduce in 3.3 and 3.4), but caused by either using an ImageLoader to load the image, or using the Image constructor that accepts a filepath to the image. Is this a known issue, that either using Image(device, imageData) or Image(device, filePath) can result in different images? As I said before, using the latter constructor results in an aliased image, while the former constructor works fine. Note that the Image was previously created on disk using the ImageLoader (not sure if thats related).
Carolyn, Is this a known bug with native image loading on windows?
Fails with HEAD public static void main (String[] args) { Display display = new Display(); Shell shell = new Shell(display); Tree tree = new Tree(shell, SWT.V_SCROLL|SWT.H_SCROLL|SWT.BORDER); TreeItem item = new TreeItem(tree, SWT.NONE); item.setText("one"); final Image image1 = new Image(display, new ImageData("D:\\449.ico")); item.setImage(image1); item = new TreeItem(tree, SWT.NONE); item.setText("two"); final Image image2 = new Image(display, "D:\\449.ico"); item.setImage(image2); tree.pack(); shell.addListener(SWT.Paint, new Listener() { public void handleEvent(Event event) { event.gc.drawImage(image1, 2, 150); event.gc.drawImage(image2, 60, 150); } }); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); }
CAR, you fixing this for 3.5? If not, please change the target milestone.
Sorry it took me so long to respond to this. Image(device, imageData) loads an image using java code, and Image(device, filePath) loads an image using native (platform) code. So, yes, the images can look different, depending on which constructor is used to load them. Note that the native loading constructor loads faster... See bug 53443 comment 11 and bug 24451 comment 51 for details. What is interesting is that you are getting better-looking results with the non-natively loaded image. Also interesting is that FireFox displays the icon properly, while IE (6.0) does not. <grin> In our native loading code we are using the GDI+ Bitmap(filename, boolean) constructor to natively load icons. Perhaps we should be using the win32 function ExtractIcon (or ExtractIconEx to load the icon array), or maybe LoadImage, instead. Since this icon has alpha data, it looks like maybe the GDI+ Bitmap loader is not loading the alpha data. Actually, I see that .ico is not even in the list of supported graphics file formats for GDI+ Bitmap(). I am changing the bug report summary to reflect this.
I just tested this again and it seems that on Linux this works (Image() keeps transparency information), however on Windows only the ImageLoader preserves the transparent information and shows the ico properly (anti aliased).
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.
