I guess Etoys always had a bit of a preference for rounded corners and softer shapes, so it may be expecting too much for rotated rectangles all to grid nicely along their top (or left) edge. As it stands
- the expandBy: 1 ensures that the rotated ones are drawn down and right from the non-rotated one
- even the rotated ones are drawn at differing positions within the expanded bounds
- in trying to see if this second effect is
an error or some profound mathematical truth, I noticed (in
versions 3.2 through 5.1 anyway) that the fallback code in
WarpBlt>>warpBitsSmoothing:sourceMap: does not function
correctly in all cases. To see this, get a RectangleMorph and
rotate it with the blue handle. Then comment out the primitive
call in WarpBlt>>warpBitsSmoothing:sourceMap:
and try rotating the rectangle again. Different, eh? I guess
figuring this out is the first step in seeing if the rotated
rects could line up nicely.
Does anything bad happen if the "expandBy: 1" is removed? I tried removing it
in my Squeak trunk image, and "CompassDialMorph new openInWorld" (which is one
user of TransformationMorph) seems to work nicely.
I bet it's there to avoid gribblies left behind when dragging. The damage rectangle needs to be large enough to cover every pixel touched even in rotated versions.
Maybe the "truncated expandBy: 1" should be something like "rounded outwards"?
But generally speaking, as long as we have the warpblt hack + integer coords instead of a proper hierarchical transform framework we will run into these rounding issues again and again.
- Bert -
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland