[squeakland] Found Bug But Not Sure How to Proceed To Fix
arning315 at comcast.net
Sat Mar 3 13:34:32 UTC 2018
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
- 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 at mail.msen.com
> <mailto:lewis at 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 at lists.squeakland.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the squeakland