Dear Jim and all, I've been experiencing some very serious problems with DirectColorModel under JDK 1.2 via an ImageProducer calling createImage(). Specifically, though I perhaps haven't tested every possible variant, if I use a DirectColorModel which does not have r,g,b masks of 0xFF0000, 0x00FF00, 0x0000FF respectively, then my image will not display correctly. Instead, it will choose the color of the left-most pixel and, ignoring subsequent pixels on the row, carry it all the way across. It will also draw very slowly. If I substitute DirectColorModel for another class identical in implementation but different in name, the image will render correctly but still suffer an extreme performance hit as it draws and redraws. This implies two things to me: (1) There is special-case code behind createImage which optimizes for certain colormodels, including DirectColorModel, and (2) this special-case code is broken. Presumably the speed overhead of using an alternative ColorModel is based on JDK1.2 using the java heap to store pixels rather than a native image peer, so the ColorModel must be queried for each pixel being (re)displayed. This is extremely troubling to me as I want adequate drawing speeds for my own ColorModels, as I had in JDK1.1. As it stands, the redraw time is much too slow on a p2-450 using the latest JIT update for JDK1.2. I would greatly appreciate any answers to the following questions: Is my theory about special cases, including DirectColorModel, being detected and treated differently in AWT image production correct? If so, does this special-case code have bugs for certain DirectColorModels causing my images to appear incorrectly? If so, exactly which ColorModels are treated specially? Is there a good way to work around this problem and get adequate speed for arbitrary ColorModels, or even different variants of DirectColorModel? The best I can think of is converting pixels to RGB before sending them to consumers, which is not particularly pleasing. I expect that I would also need to convert byte-based images to IndexColorModels or suffer the same problem. A JDK 1.1 compatible work-around would be much more desirable than a JDK1.2-specific one, although since the problem doesn't occur in 1.1, either would be workable. Bugs aside, is this the intended behaviour? I'm very troubled by even reasonably fast desktop machines not being able to handle images acceptably if they don't use one of a small range of ColorModels. Have you considered providing JDK1.1-style peer-based image production as an optional alternative to storing pixels on the java heap? This would solve problems for me, as what I'm reporting is one of several problems I've encountered with "porting" image-based code from JDK 1.1 to JDK 1.2-compatibility thus far. Thanks for any information you can provide. Cheers, Luke ===================================================================== To subscribe/unsubscribe, send mail to [EMAIL PROTECTED] Java 2D Home Page: http://java.sun.com/products/java-media/2D/
