I just tried a simple hack: A self._prev_rotation attribute is added to the sprite. The rotation values (sr, cr) are also saved as self._cr and self._sr. If the self._prev_rotation is != to self._rotation, then these values are recalculated. If the rotation value has not changed, then the previously saved attributes are used. This saves a bit of time for sprites that are rotated, but only move on the x or y axis, because three calls to the math module are skipped.
Benchmark results: Rotate Sprite only: 8.33312895099516 Move Sprite only: 4.476478230004432 Move Rotated Sprite: 6.912901834002696 On Wednesday, March 30, 2016 at 2:18:35 PM UTC+9, Benjamin Moran wrote: > > 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.
