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 pyglet-users+unsubscr...@googlegroups.com.
To post to this group, send email to pyglet-users@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
