Reading these method comment is interesting:

Color class>>colorMapIfNeededFrom: sourceDepth to: destDepth
	"Return a colormap for mapping between the given depths, or nil if no
colormap is needed."
	"Note: This method returns a shared, cached colormap to save time and
space. Clients that need to modify a colormap returned by this method
should make a copy and modify that!"

	sourceDepth = destDepth ifTrue: [^ nil].  "not needed if depths are the same"

	(sourceDepth >= 16) & (destDepth >= 16) ifTrue: [
		"mapping is done in BitBlt by zero-filling or truncating each color component"
		^ nil].

	^ Color cachedColormapFrom: sourceDepth to: destDepth


So it seems we preferred having BitBlt zero-fill or truncate the color
components...
... probably a case when making it fast > making it right in the mind
of programmers.

Nicolas

2011/5/2 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> Rendering 16bits on 32bits deserve deeper analysis.
> Last week I saw this 16bit pixel 16r7FFF, which is white with 5 bits
> per color, translated to 16r00F8F8F8, that is the same 11111 bit
> pattern shifted by 3 bits to fit on 8 bits per color.
> The bug I was tracking was the associated alpha channel 00 meaning
> 100% transparence, but the color bit pattern itself was surprising, I
> would have expected 16rFFFFFFFF.
>
> Nicolas
>
> 2011/5/2 Ben Coman <btc at openinworld.com>:
>> Jim Rosenberg wrote:
>>>
>>> When I pop on an SVG monitor to the laptop, the color anomaly occurs there
>>> too.
>>>
>> I am new to Squeak but I did 15yrs IT Support, so perhaps can offer some
>> small assistance.
>> 1. Can you make a sample code snippet with five rectangles at 100%, 75%,
>> 50%, 25%, 0%? Also please attach a screen snapshot of the result, so the
>> pixel values can be observed directly by those troubleshooting it. 2. Is
>> "SVG Monitor" a squeak package, a Windows program (which one), or a physical
>> external monitor? 3. Do the gray artifacts affect any non-Squeak windows?
>>
>> cheers, Ben
>>
>>
>