JDK-4280257 : 256 colors corrupt and flash when switch focus (win32 plugin only)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.2.0,1.2.1,1.2.2,1.3.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    solaris_2.5.1,solaris_2.6,windows_98,windows_nt,windows_2000 solaris_2.5.1,solaris_2.6,windows_98,windows_nt,windows_2000
  • CPU: unknown,x86,sparc
  • Submitted: 1999-10-12
  • Updated: 2001-03-26
  • Resolved: 2001-03-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.0 betaFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description
We are having problems running Swing applets in 256 colour mode using the
plugins from both the 1.2 and 1.3 (beta) versions of the JDK.

The specific problem is that when focus is returned to a window in the applet,
the colours flash and get corrupted.

To reproduce using 1.2.2 plugin on Win32, load SwingSet applet. If you select "The Swing Team" the menu drops ok, then if you click
elsewhere on the applet, say on one of the tabs, the menu collapses ok. However
if you drop the menu and select one of the team, the colours all flash (the GIF
and the applet). On the slower Citrix hardware we are demonstrating on this kind
behaviour looks very bad. On our much more complex application and webpage,
after a while the colours become corrupted.


Name: rlT66838			Date: 05/19/2000


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

This also occurs in JRE version 1.2.2

Set up your machine with 256 colours and run an applet in IE (4.01 SP1&2, or
5). The applet is a funny colour, often red, with crosshatch dithering over the
top of it.
(Review ID: 105078)
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin merlin-beta FIXED IN: merlin-beta INTEGRATED IN: merlin-beta
14-06-2004

WORK AROUND Use > 256 colours. This is not possible here though as it is used with narrow bandwidths from a Citrix Metaframe.
11-06-2004

EVALUATION Unlikely to fix in kestrel timeframe. Change of system palette leasd to the necessety of update of inverse color map. In our case, reference to the colormap was stored from the beginning of the session was not renewed when needed. It caused the problem. dmitry.feld@eng 2000-02-10 This wasn't a complete fix. There is still a fundamental problem in the way that we deal with colormaps inside the jdk plugin. In particular, we should never set a colormap inside the plugin because we don't own that resource. Whenever we set a colormap (which we do in the SwingSet example noted in this bug report), the process that owns the plugin (i.e., the browser) may set their own colormap, causing the flash that the customer saw. What we should do instead is simply work with the given browser colormap. There are a couple of approaches to solving this problem: - We could discontinue using our own custom colormap and simply rely on the default colormap at any time. This would avoid any conflicts with the browser process. Whether this is the best solution for the default case of a standalone applet or application is TBD. OR - We could somehow detect that we are running within the plugin and avoid any colormap sets for that applet. How to detect this is TBD. chet.haase@Eng 2000-03-23 The fix for this bug was intertwined with other palette-related bugs, but the main elements of the fix were: - detecting when we are running inside the plugin. This is done by simply checking the System property "browser" for the value "sun.plugin". - When we are running inside the plugin, we must make sure that any palette installs (via the RealizePalette() call in win32) install the palette only in the background (i.e., we will never try to install our palette as a foreground app). These items make sure that, when we are running inside a browser we accept the palette that the browser is using instead of trying to use our own. This fix has been tested and appears to work (as long as other important fixes, such as those for 4366799, are also completed). chet.haase@Eng 2001-03-14
14-03-2001