Out of screen pixels get clipped before it gets to the rasterizer - and clipping 4 vertices should not cost anything at all - you clip 4 vertices all the time with half visible sprites, etc.
There are 3 places you can change scale.
1. In the sprite collection editor, select the sprite - there's a scale parameter there. This will scale the mesh geometry, the rest of the system is oblivious to this. Use case: you have a gradient sprite which should be 256x256, but you can get away with a 32x32 one scaled 8x. Think of it as the prefab for the sprite.
2. In the sprite inspector - this changes the geometry too, but it happens at runtime. This is here so you can always have a transform.localScale of 1,1,1. This changes geometry, so the cost of this is similar to animating a sprite. Changing this will never dynamic batching.
3. Transform.localScale - this changes the transformation matrix in Unity. The problem with this is you have to be very very careful not to break dynamic batching when using this. The rules in Unity are pretty bizzare (for good reason). Different parameters make it run through different codebases with different performance characteristics.
If you need a lot of sprites which need to scale dynamically, and option #2 is too slow, make sure ALL your sprites have non uniform scales always. Something like 1, 1, 1.0001 will do. If you have a hierarchy of sprites, just changing scale on the root object will suffice.
Topic: Creating a scalable overlay sprite (Read 16138 times)
