| Proposal |
Summary
Workbench support for low color displays is incomplete; plug-ins cannot supply low and high color versions for all of their graphics. Supporting low color requires the workbench to provide new extension-point attributes, define a shared low color palette, and provide additional utility classes. Plug-ins would need to provide two versions of all graphics, and duplicate the approach taken by the Workbench. Given the infrequent use of low color displays, SWT's nearest color matching support which ensures graceful degradation and the lack of complaints about missing low color support it is felt that providing specialized low color is unneeded. In addition, there is a reasonable cause to believe plug-ins would not correctly mimic the workbench low color support when looking up images.This proposal recommends that graphics artists design for high color displays and that they be permitted to use up to 256 colors in a given image and that each image can use its own set of colors. The Workbench's partial low color support will be deprecated. This proposal does not affect SWT.
If this proposal is accepted the workbench team will do additional investigations to determine the list of impacted APIs or extension points.
By Kevin Haaland and Greg Adams, OTI
Last Modified: November 19, 2001
The SWT Color Model provides support for low (8 bit) and high color (> 8 bit) displays. On low color displays there are 256 available colors. When you allocate a color you will either receive a Color with the exact RGB values that you asked for or a reasonable facsimile (the closest match that could be made). To avoid running out of colors SWT requires applications to allocate colors and dispose of them when they are no longer required. On high-color displays (16 bits and higher), every Color allocation is guaranteed to succeed. SWT also provides access to the standard colors through Display.getSystemColor(int).
For more information on the SWT color model read the article entitled SWT Color Model .
On low color display windows will reserve colors for
On low color displays (8 bit) , or on high color displays where the user has
set their mode to be low color icons (i.e. by unchecking "Show icons using
all possible colors" or similar setting) any icons shown in SWT trees,
lists will only use the 16 system colors.
SWT uses the X shared color map. On RH 7.2 virtually all colors are preallocated out the shared color map. This means an application requesting a specific RGB color value is unlikely to receive it.
SWT could be altered to use its own color map instead of allocating colors from the shared color map however this would increasing flashing as you switched between applications thereby causing the color maps to be swapped.
The appearance on Linux is effectively what Windows low color users will see as a result of this proposal.
The workbench includes partial and therefore incomplete support for low color displays. If the Workbench provides low color and high color support for a given area this typically implies that plug-ins can supply both low color and high color graphics and the platform implicitly chooses the appropriate image based on the color depth.
The Workbench provides low and high color support in several areas:Unfortunately most extension points that take an icon as an extension attribute (e.g. new wizard, perspective, actions, editors etc.) do not allow the contributing plug-in to supply both low and high color versions of their graphics. For example in the following JDT perspective extension you will observe only one icon declaration.
<perspective
id="org.eclipse.jdt.ui.JavaHierarchyPerspective"
name="%typeHierarchyName"
icon="icons/full/cview16/hierch_persp.gif"
class="org.eclipse.jdt.internal.ui.JavaHierarchyPerspectiveFactory" />
Plug-ins declaring graphics in their code would need to check the color depth and determine which of their images to use. For example the WorkbenchImages class does this in its static initializer. Ideally all plug-ins would adopt a consistent naming convention. There is also the "possibility" of a utility class providing the functionality below however it would still need to be called/used by plug-ins.
public final static String ICONS_PATH;
static {
if(Display.getCurrent().getIconDepth() > 4)
ICONS_PATH = "icons/full/";//$NON-NLS-1$
else
ICONS_PATH = "icons/basic/";//$NON-NLS-1$
}
Lastly, a plug-in that allows icons to be provided for any of the extension-points it declares would also need to allow the contributing extension to provide both a low and high color version and then choose the right one to use based on color depth.
This would require the following support be added:
This would require a graphics artist to ensure:
Unfortunately, because we cannot constrain the number of plug-ins it is conceivable that the limited set of colors will quickly be used up. Looking at the numbers we can see that the Workbench declares approximately 40 colors. This means:
On Windows there are (256
- 20 - 40 = 196) to be shared by all plug-ins. This number is also subject to
change if the Workbench uses more colors. In addition, it is a first come first
served. Your chance of getting your exact colors depends on luck (few other
plug-ins allocating colors, or your is an already allocated color) or timeliness
(your plug-in starts first).
On Linux RH 7.2 the number
is less (see Reality 3), in fact virtually no free colors exist and consequently
you will receive a nearest color match.
Even if you are good citizen allocating and deallocating colors there is no guarantee you will get the color. Typically your color selection will be based on nearest color match.
Same as option 1a however in order to address the "randomness" of what colors are available the workbench or SWT would predefine a palette. This would happen in one of two ways:
Plug-in providers would design their low color graphics using the predefined palette. High color graphics would still be contributed separately using any colors.
There are several problems with this:
Bottom Line - A portable palette is not currently definable (color cube or custom palette) for low color displays. The odds of receiving a color by nearest color match is high. Hoping to successfully communicate a predefined palette is "optimistic". In addition if low color displays are far and few between (for eclipse clients) this argues that it is interesting to support it but not necessarily in a first class way if the tradeoff is added complexity..
This approach would require no special plug-in or workbench support. Graphics artists would construct 8 bit images containing any 256 colors. Each image could have a different set of 256 colors. The reason for this 8 bit limit is to avoid performance degradation when SWT maps the image colors to the ones available on the display. Higher color depth images (> 8 bit) require more work to be done during this mapping.
SWT has indicated the following observations apply on all platforms:
+1 = You are in favour of this proposal & agree with further exploration to determine API/contribution changes.
0 = Abstain
-1 = You are opposed to this proposal. When voting -1 you must also provide a detailed explanation of your reasons.
Voting ends 1 week from date proposal is submitted to the mailing list.