Community
Participate
Working Groups
The SWT implementation on GTK supports only 24-bit color depth as is evident from the following lines in getImageData() in the Image class: PaletteData palette = new PaletteData(0xFF0000, 0xFF00, 0xFF); ImageData data = new ImageData(width, height, 24, palette); This is particularly problematic for us as we need to be able to determine the device depth based on the pixel size of an image. If you take a look at the Windows or Motif implementation, there are switch/case statements to deal with different color depths. For example, we tested (and it worked) on a 16-bit monitor with the following change- PaletteData palette = new PaletteData(0x7C00, 0x03E0, 0x1F); ImageData data = new ImageData(width, height, 16, palette); These values are from our calculation and match with the Windows implementation of 16-bit color depth.
I remember that code (since I wrote it a while back :-)). The code was just written by creating a image and than getting the image detph/palette, because SWT did not have an API then (I believe SWT032). You should call display.getDepth() and SWT should provide an API to get the system palette. PaletteData Device.getSystemPalette() { ... }
Oops, I thought I'd already responded. Guess I forgot. The problem is it's not up to us to simply call getDepth(). The TCK for Personal Profile does as I described in my email to you and there's nothing we can do about that. Sorry I should have included the information from that email here. Here it is: This problem gets into a lot of detail about how much of the graphics tests work in the Personal Profile TCK. The bottom line is that AWT doesn't have an obvious method for determining the screen depth (like SWT's Device.getDepth()). Rather, it creates an image, gets it's color model and asks for the pixel size. It is very important that when running on low depth displays, that the tests be able to detect this through the method I just outlined. However, in the current GTK implementation, image palettes are always created as 24-bit color.
I thought AWT programs would call java.awt.Toolkit.getColorModel() to figure out the depth/palette of the screen. That is why for me it would be enough just to provide Device.getSystemPalette(). It is kind of wrong to expect that images will always be on the depth of the screen. Right now, GTK is always 24/(0xFF0000, 0xFF00, 0xFF), Carbon is always 32/(0xFF0000,0xFF00,0xFF) and Photon is 24/(0xFF0000,0xFF00,0xFF). On Photon, images may have other depths if created using the constructor Image (Display,ImageData). How does AWT creates the image? Is it calling Image(Display,ImageData) or Image (Display,int,int)?
You may well be right that that's what AWT programs could/should be doing. However, it is not what the Personal Profile TCK does and there's little we can do about that. Specifically, what they are doing is something like this (I say "something" since I can't look at the exact source ;-)). GraphicsEnvironment ge= GraphicsEnvironment.getLocalGraphicsEnvironment(); GraphicsDevice gd= ge.getDefaultScreenDevice(); GraphicsConfiguration gc= gd.getDefaultConfiguration(); BufferedImage bi= gc.createCompatibleImage(100,100); int depth= bi.getColorModel().getPixelSize(); Why they go through all this trouble as opposed to doing Toolkit.getDefaultToolkit().getColorModel().getPixelSize() is beyond me, but they may well have their reasons. Anyway, the more complicated path works on Win32, PocketPC and Motif, but results in an incorrect depth on GTK. Carbon isn't and may never be an issue for us, but Photon is an interesting heads up for us as well. I'll have to look into the details of how we implement this code path to see if we can't leverage Device.getSystemPalette() to make this work. From the code, it seems we get the ColorModel (as returned by Toolkit.getColorModel) as follows: - create an image by using Image(getDisplay(), 1, 1) - get the paletteData from the imageData taken from that image - we then construct either an AWT DirectColorModel or IndexColorModel based on whether the paletteData isDirect using (among other arguments) imageData.depth. So that's how we create an image for determining the color model. However AWT creates images using both of those constructors depending on the circumstances in other parts of the code.
*** Bug 45571 has been marked as a duplicate of this bug. ***
I'm probably going to close this bug unless someone gives a good reason not to. This sounds as not useful nowadays. Nor even has an idea what this Personal Profile TCK is about.
No reply in 9 months closing.
