Re: [platform-ui-dev] VOTE: Low Color Proposal (end date = 11/27)

["Jeff Brown" <j9brown@xxxxxxxxxxxxxxxxx>]

I disagree.

> However, I believe the argument that SWT will degrade high-color images on
> 256-color displays is a false one.  If the SWT System palette has 40
> entries (someone mentioned that the workbench reserves around this many
> colors), and I load an Image that has another 200 colors in it, the SWT
> system palette will not change, it will still have just 40 entries.  So,
> that Image will degrade to some unknown number of colors, not necessarily
> 256.

My current thinking is that anyone who cares about how good/bad images
will look onscreen is likely running some high-colour mode already.  Image
degradation can be mitigated with dithering.  SWT's ImageData has some
limited internal support for ordered dithering.  It's not accessible via
public
API, but with enough pressure perhaps...

> Similarly, if I paint a gradient of Colors onto an Image much like the
> ViewForm does in Eclipse, I must hold onto those Colors .  If I dispose
> them, the gradient Image is no longer valid because the blues used to
paint
> the gradient may get bumped out by come other colors.

SWT now has support for drawing simple linear gradients without needing
to generate and hold on to all of the intermediate colours.  On low-colour
displays, rather than wasting precious pens, it uses an ordered dither which
tends to look quite good.  See org.eclipse.swt.graphics.GC.gradientFill().

> This can be solved with a Color Cube.  SWT may have decided against the
> Color-cube, but Eclipse can still define one.  This may be the right
> decision both for SWT and Eclipse.  This way, you can be sure that if you
> load a high-color image it will degrade to a meaningful set of 256 colors,
> not 40 colors.

In thie case, either Eclipse shares the desktop's colour map which may
have very few free pens remaining or it creates its own.  It is highly
unlikely
that Eclipse could get the full 216 pens needed to make a 6x6x6 colour
cube unless it loaded a private colour map.  Applications that load
private colour maps do not tend to play nice with the desktop.  Switching
between applications with different colour maps causes a noticeable
flicker and delay.  On Windows, the entire screen is redrawn to conceal
the effect.  On X, you're left with a bunch of UGLY windows onscreen
remeniscent of false colour astronomical surveys.

I agree that having to dispose() Color objects is a major pain, but using
a colour cube will not help matters since you must STILL release those
Color objects even though they're rather useless.  The best way to
prevent image degredation is to draw everything to an offscreen bitmap
ImageData then create an Image from it and trust the platform to
do the best it can to make it look good when you actually draw it.
But then, as I said, most people use high colour displays nowadays
-- especially developers who tend to have fairly high-end equiment
and are the target audience for Eclipse.  I doubt many people will
legitimately complain about image degredation in an IDE!