+1 on Daniel's idea, and you're probably right about the issues w/memoization & Py2.x Let's see what Daniel's suggestion yields.
On Thursday, March 31, 2016 at 10:05:13 PM UTC-4, Benjamin Moran wrote: > > Serdar, > > Memoization is a nice idea, but it might be too much to consider maximum > sizes and all that entails. The self._prev_rotation attribute is sort of a > per-sprite buffer already, so I would imagine the speed would be similar. I > love the functools.lru_cache decorator in Python 3, but unfortunately that > one is not available for 2.7 in the standard library. Still, it might be > nice to try a simple custom routine to see what it can do. > > Daniel, > > I think that's a fantastic idea. It might be best to do a separate pull > request just for adding that method. The changes I've made in this branch > are fairly big for a pull request, and I'm still not even sure if Rob or > Leif would be interested in merging them Since your idea would make sense > even by itself, it's probably better to do a seperate single pull request > for that. I'm not sure how they'd feel about your proposal either, but it > does sound really useful to me. Maybe something a little different, in case > you wanted to update the x coordinate and rotation, but not y: > > > def transform(self, x=None, y=None, rotation=None, scale=None): > if x: > self._x = x > if y: > self._y = y > if rotate: > self._rotation = rotation > if scale: > self._scale = scale > self._update_position() > > > > > > On Thursday, March 31, 2016 at 10:23:34 PM UTC+9, Daniel Gillet wrote: >> >> Hello, >> >> Funny enough, I was also thinking a bit about the Sprite class. I >> remember a discussion on this group (that I cannot find again) where it was >> shown that if you move and rotate a Sprite, you will end up updating twice >> its vertices. >> >> I had a good look at how things are implemented. I was thinking about >> some sort of lazy vertices update, but it's not possible as the data may be >> actually in a batch. The batch knows nothing about Sprites, it only knows >> about its VertexLists. So when the time comes to draw its data, it would be >> cumbersome to go through that list, try to figure out to which Sprite it >> belongs to and call its _update_position method. >> >> So I would suggest to add a new method to the Sprite class which would >> allow the user to move, rotate and scale the sprite altogether. Maybe call >> it something like >> def transform(self, position=(0.0, 0.0), rotate=None, scale=None): >> if move != (0.0, 0.0): >> self._x, self._y = position >> if rotate is not None: >> self._rotation = rotate >> if scale is not None: >> self._scale = scale >> self._update_position() >> >> For Sprites that only rotate, move and/or scale once in a while, this is >> unnecessary. But for Sprites which do that on every frame, say an asteroid >> which is rotating while moving slowly, there could be a nice speed up. >> >> Adding a new method would not break any existing code. It should be added >> to the documentation that if a Sprite is constantly moving, rotating and/or >> scaling, this new method would be more efficient. >> >> Daniel. >> >> On Monday, March 28, 2016 at 7:02:01 AM UTC+2, Benjamin Moran wrote: >>> >>> Hi guys, >>> >>> I did a minor performance tweak to the Sprite class's _update_position >>> method a while ago, and thought I'd share it. You can see it in my >>> "sprite_optimization" branch here: >>> >>> https://bitbucket.org/treehousegames/pyglet/src/124e1fe4c0016cf9effcf3c1706c0124aa99712e/pyglet/sprite.py?at=sprite_optimization&fileviewer=file-view-default >>> Basically it's just cutting out the temporary vertex list creation, and >>> removing a if/else few checks. I've tested it with a few thousand sprites, >>> and this nets a few extra FPS. Not a major improvement, but it's also a bit >>> easier to read the method in my opinion. >>> >>> The only drawback to this tweak is that Sprite vertex_lists are always >>> created as float arrays, even if sprite subpixel is not used. This is to >>> avoid one of the if/else checks in the method. It is my understanding that >>> on modern GPUs (last 10 years), floats are used internally anyway, so this >>> shouldn't hurt performance any. >>> >>> Would this make sense to try to get merged in, or is there some glaring >>> issue that I'm missing? >>> >>> -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
