Animations flicker in DebugAnimations due to performance regression

[jkomoros]

While working on #396 noticed that animations flicker in debuganimations game: the card is briefly visible before the transition in its final location before animating.

Happens in canary and stable channel Chrome. Doesn't happen in memory or blackjack, only debuganimations.

I imagine what's happening is that the calculations take more than a frame or two in expensive situations like debug animations, so they're visible there. Still, should be possible to hide that somehow.

[jkomoros]

Likely only noticeable now on MBP, not before.

Some mitigation options: do a fast check for no inverse transform for components that are in the same component stack + index + stack_layout_type as possible and skip most of the processing for them.

... There must be others

One test is if they are the same physical element before and after (also setting transforms by component stack should be via a setter, so if they haven't changed as well as being same physical ele can skip animating)

[jkomoros]

Before digging in on a fix, do a performance analysis of the animation and see where the most time is being spent. Perphaps a layout trash was introduced at some point

[jkomoros]

Actually, although the specific issue was fixed, the performance of the animations still is really bad (especially on mobile), and should be improved.

In profiling it looks like _updateClasses is pretty slow, because instead of actually passing through the properties, we read them back from this, which presumably is pretty slow. The current design is a kind of hack to make sure that the class is recomputed, while not requiring every user of it to redefine rewire all 7 or whatever different properties down.

[jkomoros]

Another thing that is really slow for e.g. pass and debugAnimations is that the altShadow creates some really expensive rasterization.