Sprite scale: Preserve performance #2389
Conversation
|
Id like to try one last thing before we go ahead. Since the biggest cost with the Vec2 is around creation and GC I wonder if making a slotted murable Vec-like with support for piecewise operations would be performant enough. Like working with lists it may have a few hickups, but Ill implement |
I'm curious to see this before we push this one through -- the DX is a tad clunky and it won't be forward-compatible with 3.1. I'm fine with it if Dragon's proposal doesn't get done/isn't up to snuff, though, I agree it's a better option then lying to the user as to what the underlying scale is. |
|
The amount of things that broke due to this change was minuscule so I'm not too worried. The new methods are also a lot faster than the scale property can be. Especially when adding and multiplying scale simply because it's one callable less compared to This also needs to be checked before merge. Ensure all subclasses of |
The names we had for the scale methods didn't feel right for arcade/python so they have been changed to be more readable. While the concern about confusing the user is valid I think the change is worth it. During the interim before we do a larger re-write this is a nicer developer experience than using a method. Most developers set the sprite scale once, and then don't change it in the future. the `isinstance` check for `AsFloat` is no-where near the cost of creating a vector. In my ideal world sprite would not have a scale property at all, and instead scale is a method that changes the size of the sprite.
The
Sprite.scalechanges made the property 4-5 times slower. Instead we introduce methods to handle uniform scaling.