This will be very important, though there's some chicken-and-egginess to sort out with the frame production lifecycle. We currently need our texture size before we know our world space transform.

We've mostly addressed this now.  Because we used the ScaledDepthAdjuster, element sizes are generally in DMM.  We can convert size to texture size, as the text element does, by using a fixed ratio.

However, we'd want to ensure that if the size animates for some reason, that we don't redraw a texture every frame during the animation.

I think this bug also refers to dynamically computing an optimal resolution based on the display's resolution and element size in projected space as we do it for the content texture.

/re the animation, for the content quad we choose the target value of the animation to calculate the resolution.