See RFE 4281429 for a previous discussion of the suggested fix.

I've implemented, using JAWT, a component for Solaris to draw a java.awt.Image
using native X11 methods. This is intended to test the ability of a JAWT
client to use lots of colors. The intended purpose for JAWT is supporting
reuse of native code inside the Java framework, and often those kinds of
modules are graphics intensive with lots of colors.

On X there is a difficulty in calculating the correct pixel value in order
to represent the correct color. The calculation of the pixel value varies
depending on the X Visual used by the window.

The first (simple) approach I originally took was to mimic code I found in
the AWT source tree. For an 8-bit display (what I have on my workstation) this
devloves to calling XAllocColor and returning the pixel value it gives me.
While this worked fine for simple cases where one color was used across a whole
component, and only a small number of colors used in the entire application,
this did not work when displaying a GIF image.

With the GIF image, most of the colors of the image were missing. If I make
the same app draw the same Image object using Java methods (Graphics.drawImage)
it draws perfectly in the same application where using JAWT it is drawn badly.

As a workaround I implemented a function that, using Solaris dynamic linking
support, calls the functions internal to the AWT source that handle color
allocation for the rest of Java. Using this workaround, the same image is not
only drawn correctly, it is drawn BETTER than if it is drawn using the
normal Java methods.

=====================================

Further addition: The same issue is seen on the Windows side as well if you
set the display resolution to 8-bit (256 color).

It is less of a priority for Windows than Unix since 16-bit or higher
resolution graphics cards are much more common there (huge price difference
between $100 or so for an ATI Rage XPert@Work vs the $2000 or so for a
fancy Sun frame buffer).