BitBlt primitive bug

sqrmax at sqrmax at
Tue Feb 9 21:44:15 UTC 1999


If the primitive of drawLoopX:Y: fails, after returning it will have 
touched (at least) destY making the code executed afterwards draw somewhere else. 
It has happened to me with vertical lines. I think the primitive fails because 
the screen depth is 16 bits and I wanted to perform alpha blending on it, 
hoping that it would work. I think that it will also touch destX as well, but I 
haven't noticed since I was drawing vertical lines. The effects of this bug 
were quite funny... after tracing the source in drawFrom:to:withFirstPoint: 
in BitBlt to the point of sending drawLoopX:Y:, destY was say 100. And when 
tracing, the source code below the primitive would pop up with destY now 
something else as if by magic!

I browsed the C code for the primitive. It has a null return in case of 
failure that is placed after destY and destX are modified. When this error 
happens, the values of destX and destY will be returned modified and so the 
subsequent code will throw pixels somewhere else (exactly at the end of the line 
just 'drawn nowhere'). I'm no expert in primitives, what would be the best 
thing to do? To store destY and destX in temp variables in the C code and 
restoring them if something happens? To check for translucent colors before doing 
anything and returning an error before working? Can something else fail making 
the recovery variables a must? I don't know if translucency should be 
expected to work after all. I remember that Dan wrote something about a new mode for 
alpha blending with less than 32 bit deep displays...


More information about the Squeak-dev mailing list