This appears to be broken for a very long time. I had to go back to Squeak
2.8 to see it work properly (enter the Play With Me 3 project, then rotate
the TT morph, also move the gray center-of-rotation handle):

http://tinyurl.com/mvte9wm

In 3.8 the TT morph is broken same as now, but the Flash renderer uses
MatrixTransformMorph. Rotate the SqueakLogo to see it in action:

http://tinyurl.com/ksztj76

Interestingly, FlashMorph is a *subclass* of MatrixTransformMorph. Maybe
that's the intended use?

- Bert -

On Thu, May 18, 2017 at 6:30 AM, tim Rowledge <tim at rowledge.org> wrote:

> In my (apparently quixotic) quest to draw nicer barometers I decided to
> try out MatrixTransformationMorph, since it purports to allow transforming
> morphs and display them via Balloon with anti-aliasing etc.
>
> Well, that didn’t go so well. It appears that MTM is really pretty badly
> broken. Mostly that isn’t going to worry anyone since it seems to only get
> used when making a flex shell for a TTSampleFontMorph, which is only ever
> used if someone tries out the truetype sample morph from the ‘objects’
> catalogue morph - and then rotates it as well.
>
> I’m having a lot of trouble making any sense of what is going on because
> there is no documentation to explain what is supposed to happen. Which
> makes it hard to decide which of the many places where things go awry is
> the actual bug.
>
> It’s possible that this is so un-useful that we’d be better off removing
> the entire class. Leaving that aside for a moment, let’s list some of the
> problems -
>
> Attempting to make a new MTM and set its extent will make a completely
> ridiculous  transform, because #extent: treats this as a grow from the
> default extent (which is 40 at 50) and scales the transform to scale that up
> to the new extent. Probably a good idea in many situations but a bit of an
> issue ab initio.
>
> When attempting any rotation (which is exacty what I wanted the $%^%^#%
> thing for) makes for real fun. Correct me if I’m wrong but the rotations
> are calculated about the referencePosition which is derived at least in
> part from the rotationCenter. Which appears to be expected to be a
> fractional point giving the relative proportion within the bounds - ie the
> center is 0.5 at 0.5. First problem is that the MTM code was treating 0.5 at 0.5
> as an actual pixel offset. Sigh. I added a scale by the extent and that
> seems to improve some things. Then we have the converse issue with
> #rotationCenter: doing some scaling that resulted in the rotation center
> value being set to a pixel offset instead of a fractional one! Hacked that.
> At least part of the problem seems to be some confusing mixing of
> #rotationCenter: and #setRotationCenterFrom: (the latter actually taking a
> pixel offset and converting it to a fractional value).
>
> If we make a nice simple needle morph out of a PolygonMorph and stick it
> inside an MTM and display it, initially the MTM bounds are completely
> unrelated to the polygon. If we then send the MTM #rotateBy: 10, the
> rotation proceeds about an incorrect center because that point is
> calculated from those incorrect bounds - and then the bounds are
> recalculated to fit around the (mis)rotated polygon. So the next rotation
> has a *differently* wrong center! To add to the fun, the only live usage
> code (#asFlexOf:) carefully recalculates the bounds after adding the morph
> it is a flex-shell of. Though only *after* calculating the rotation center
> based on the bounds of the submorph and the incorrect bounds of the MTM.
> Which *really* screws things up.
>
> Maybe the lack of any sort of explanation of how this is supposed to
> behave is simply confusing me so much I’m "not holding it right". Maybe it
> used to work and got left out of being updated when something fairly
> low-level got changed. Does anyone know? Does anyone care much?
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: CSF: Charge to NSF
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170518/51ce46cb/attachment.html>