I did some reading about that, and it seems like it wouldn't work out very
well. I'm no expert on such things, so it may be possible. The overhead
would likely nullify any advantage in doing matrix calcs. If I'm not
mistaken, the OpenGL book actually recommends doing it the pyglet way if
you're using a vertex buffer.
Anyway, I did some benchmarks with the timeit module of the current
improvement. The current pyglet Sprite class nets the following results:
Rotate Sprite only: 8.60662043200864
Move Sprite only: 5.625210800993955
Move Rotated Sprite: 8.608534647006309
My sprite_optimization branch has the following results:
Rotate Sprite only: 7.774088190009934
Move Sprite only: 4.467840968005476
Move Rotated Sprite: 7.779906847994425
On Wednesday, March 30, 2016 at 2:45:18 AM UTC+9, Serdar Yegulalp wrote:
>
> Wasn't there also discussion at some point (perhaps far earlier on the
> list) of having the rotation code handled in OpenGL itself? If that's at
> all possible, that sounds like the best solution.
>
> On Tuesday, March 29, 2016 at 5:16:42 AM UTC-4, Benjamin Moran wrote:
>>
>> Not a bad idea. I've updated it with an extra _update_position method,
>> and the _create_vertex_list method now sets the proper one.
>> This will save another if/else check now, but I wonder if it's a little
>> messier.
>>
>> This should now be functionally identicle to the current pyglet Sprite
>> class, but a bit faster at the expense of a few more lines of code. I
>> wonder if this is worth doing a pull request for? The main reason the
>> _update_position class is slow is when rotation is set, due to all of those
>> vertex calculations. It would be nice to go over that code as well, and see
>> if there is any way to trim it down a bit.
>>
>>
>>
>> On Monday, March 28, 2016 at 10:10:19 PM UTC+9, Serdar Yegulalp wrote:
>>>
>>> One possible tweak that could be made to that is something that could be
>>> either a Sprite creation option or an environment flag -- to have either
>>> int or float arrays created by default, by way of swapping in one function
>>> vs. another. The latter way, you'd only need to do one check at __init__
>>> time for the whole library; the former way could probably be optimized to a
>>> high degree in a similar fashion.
>>>
>>> On Monday, March 28, 2016 at 1:02:01 AM UTC-4, 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.
