[BUG] drawing translucent text

Bob Arning arning at charm.net
Thu Jun 24 16:46:34 UTC 1999

Changing a TextMorph from opaque to translucent changes the position where the text is drawn. This effect can be seen by creating a new TextMorph. Open an inspector on this morph and in the inspector alternately evaluate:

self color: (Color black alpha: 0.5)
self color: Color black

Wonder of wonders! The text moves when the color changes! After much poking around, I have discovered that CharacterScanner>>scanCharactersFrom:to:in:rightX:stopConditions:displaying: fails the primitive (103) whenever translucent text (combination rule 31) is drawn. What causes the shift in position is that destX is incremented by the width of the first character even though nothing has been drawn. The Smalltalk code after the primitive then begins drawing the entire string from the wrong position. My guess is that the error lies in BitBltSimulation>>copyBits in the fragment below:

	(combinationRule = 30) | (combinationRule = 31) ifTrue:
		["Check and fetch source alpha parameter for alpha blend"
		interpreterProxy argCount = 1
			ifTrue: [sourceAlpha _ interpreterProxy stackIntegerValue: 0.
					(interpreterProxy failed not and: [(sourceAlpha >= 0) & (sourceAlpha <= 255)])
						ifTrue: [interpreterProxy pop: 1]
						ifFalse: [^ interpreterProxy primitiveFail]]
			ifFalse: [^ interpreterProxy primitiveFail]].

which is sent from BitBltSimulation>>scanCharacters in the fragment below:

			scanDisplayFlag ifTrue: [self copyBits].
			destX _ nextDestX.
			interpreterProxy storeInteger: BBDestXIndex ofObject: bitBltOop withValue: destX.

No test is made here for the #copyBits failing, so destX gets updated even though there was nothing drawn. Since the above code is in the VM, it's a bit hard to debug.

While a patch could be applied at the Smalltalk level (wrapping the primitive 103 in another method which would preserve destX in the event of failure), it would be better if the VM could be fixed. I also do not know if this probelm appears under other circumstances (like non-text drawing).


More information about the Squeak-dev mailing list