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.
On 3/3/18 7:44 AM, Bert Freudenberg wrote:
On 3 March 2018 at 02:37, David T. Lewis <lewis@mail.msen.com mailto:lewis@mail.msen.com>wrote:
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