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

[Greg_Adams@xxxxxxx]

Randy,
The voting closed a little while ago, but your input is appreciated.  I have included some comments below for your information. Probably the most interesting is the color cube note at the end. I suspect there is no need to reply since your points are useful clarifications and we'd be discussing the fine points of something we agree on<g>.

"Randy Hudson" <hudsonr@xxxxxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx 12/11/01 02:23 PM Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-ui-dev] VOTE: Low Color Proposal (end date = 11/27)

I'm in favor of the Low Color proposal.

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.


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.

<greg> 
Correct. This is discussed but not repeated in option2 . Specifically,
the degredation depends on several things including(discussed elsewhere in the article):
1) whether the color is already allocated & hence is available
2) whether their is a free slot in which the color can be allocated.
As indicated on some platforms more slots are taken before you even get your colors<g>
</greg>


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.

<greg>
A color cube is discussed in option 1b. 
In addition to the issues discussed in 1b, another potential issue is that by the time the eclipse UI gets a chance to allocate itself a color cube, many of the colors may be gone on some platforms. If we go down a color cube or custom palette path it will be important to provide some commonality to it across platforms or it is likely this will cause grief (based on discussions with artists). We would also want a rich enough cube.

An interesting observation you make is whether swt should define a color cube.  Following on from this I would observe that dispose() exists to support low color displays (since it does nothing on high color displays).  If we believe that most devices are tending away from low color, then it seems odd to require most clients to have to manage color resources. Reading the swt color article it also seems to support that perhaps swt should just allocate a color cube on the far-and-few-between low color only displays, and thus relieve 90% of developers from having to explicitly manage their colors.  If this is what led you to the observation you made, then you might want to follow up your idea with the swt mailing list
</greg>






_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev