MatrixTransformMorph appears to be as broken as a very broken thing

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@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@0.5. First problem is that the MTM code was treating 0.5@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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CSF: Charge to NSF