[squeak-dev] Color>>quickHighLight: problems with transparent images

tim Rowledge tim at rowledge.org
Mon Oct 27 20:52:41 UTC 2014


The Color>>quickHighLight: method is ancient and appears to be wrong when using ‘modern’ pixel values where 0 is transparent and 16r1 is black. The use case is getting a decently visible colour for a cursor when painted onto an arbitrarily coloured background image. Strictly speaking a bitwise reverse isn’t a perceptually reliable algorithm but it is at least quick and usually tolerable.

Consider the following code -
|bitBlt bufferForm|
	bufferForm := Form extent: 100 at 20 depth: 32.
	bufferForm fillWhite.
	bitBlt := (BitBlt toForm: bufferForm)
		clipRect: bufferForm boundingBox;
		fillColor: (Color quickHighLight: bufferForm depth);
		combinationRule: Form reverse.

	bitBlt
			destRect: (0 at 0 extent: (bufferForm width /2) @bufferForm height);
			copyBits.
		bufferForm displayOn: Display at: 0 at 0 rule: Form paint

What one wants to see is a patch in the top left of the Display with a 50x20 black area and a 50x20 white area. You get 50x20 transparent (ie nothing visible) and 50x20 white.

If we change the code to 
|bitBlt bufferForm|
	bufferForm := Form extent: 100 at 20 depth: 32.
	bufferForm fillWhite.
	bitBlt := (BitBlt toForm: bufferForm)
		clipRect: bufferForm boundingBox;
		fillColor:  (Bitmap with: 16rFFFFFFFE);
		combinationRule: Form reverse.

	bitBlt
			destRect: (0 at 0 extent: (bufferForm width /2) @bufferForm height);
			copyBits.
		bufferForm displayOn: Display at: 0 at 0 rule: Form paint
… then we see what we wanted.

I’m not completely convinced that changing the Color>>initializeHighLights method to - 
initializeHighLights
	"Create a set of Bitmaps for quickly reversing areas of the screen without converting colors. "
	"Color initializeHighLights"

	| t |
	t := Array new: 32.
	t at: 1 put: (Bitmap with: 16rFFFFFFFF).
	t at: 2 put: (Bitmap with: 16rFFFFFFFF).
	t at: 4 put: (Bitmap with: 16r55555555).
	t at: 8 put: (Bitmap with: 16r7070707).
	t at: 16 put: (Bitmap with: 16rFFFFFFFF).
	t at: 32 put: (Bitmap with: 16rFFFFFFFE).
	HighLightBitmaps := t.

… is completely correct, but it might be. Does the 16bpp case need changing? Is there a bitblt rule I’m unaware of that does things better?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful Latin Phrases:- Fac ut vivas. = Get a life.




More information about the Squeak-dev mailing list