hi padraig! i'm so glad that someone actually looked at the code!
On Dec 2, 5:07 pm, Padraig Kitterick <[EMAIL PROTECTED]> wrote: > You might consider making the current code more efficient by reducing > the number of static values that are recomputed on every update cycle. > For example, on every move operation you calculate (in _move): > > self.tile_size * self.mapset.width - self.vp_width actually self.tile_size changes when zooming - the smaller the tile size the more zoomed out. i could also have a fixed tile size but then i would have to multiply it with a zoom factor which leads to the same > > which as far as I can work out shouldn't be changing necessarily with > every movement (I could be wrong - I just glanced at the code). Again, > in the update method, called 60 times a sec, you calculate: > > (self.tile_size-32) > ((self.tile_size-32)*3) same here > > on every call, which are probably static values in most cases. Also, I > don't know how often you update your vertex lists, but the following > initialisation code: > > vertices = [[] for value in self.mapset.groups] > tex_coords = [[] for value in self.mapset.groups] > count = [0 for value in self.mapset.groups] > > allocates memory on every call to update_vertex_lists. If this function > is called frequently, it would me more efficient and faster to keep > those lists in memory (i.e. persistent), and clear their contents when > needed and thus avoid the slower option of repetitive memory allocation. > It's also not the best way to allocate an empty list: > > ngroups = len(self.mapset.groups) > vertices = [[]] * len(self.mapset.groups) > tex_coords = [[]] * len(self.mapset.groups) > count = [0] * len(self.mapset.groups) > > would probably be faster as it avoids accessing the individual values of > self.mapset.groups. If the number of groups changes frequently, then > it's still probably more efficient to make the lists large enough to > handle the maximum likely number of values, but make the allocation once > at the start of the program. thanks! intersting suggestion! i will implement this! > > You might also want to look into Cython or Pyrex to optimise parts of > the code that are called often. By being careful about memory > allocation/deallocation, I have gotten extremely large speed increases > using Pyrex for functions called many times a second. i already had a look into rabbyt that used pyrex. my initial goal was to have everything in python without any compilation - i'm rethinking this now. > > It's possible to write very efficient code in Python, in terms of > execution speed, but with code that is looped at high frequency, even > the smallest increase in per-cycle computations can lead to much slower > performance. If in doubt, search the python mailing list and google - > there is quite a bit of info about which operations are more memory > efficient or which result in new memory being allocated. It's may be > that your performance is suffering more from these kind of issues rather > than from the ctypes calls. > > P. > ** okay a few general thoughts: of course most of your suggestions are right, but most of them only change the speed in the milli to microseconds: the self.tile_size calculations for example. also the list creations are ONLY done when resizing the window or after there was a zoom in or out. what i am curious about is the performance that i get when only rendering is done. so my code does nothing and all that is done is done by pyglet which draws the current batch's content. this is rather slow - below 30fps most of the time and depending on hardware and zooming even below 15fps. this is something i cannot change without changing pyglet itself and this is something that is only due to gl ctype calls. what i really can improve with pyrex for example is the code that gets executed on moving around ( _move() ) because this is only a nested loop and some array filling and this can certainly be greatly enhanced by a natively compiled module. i'm very grateful that you took the time to look at my code! i will include your improvements for sure. it's just that it doesnt really matter now to optimize in the range of milliseconds when the entire part that pyglet itself does takes up to deci seconds... On Dec 2, 5:08 pm, "Tristam MacDonald" <[EMAIL PROTECTED]> wrote: > Do you have an idea of how many draw calls are being issued when you use > pyglet's rendering? And how many triangles are being rendered with each > call? > > Ideally, to overcome the ctypes overhead, you need to be rendering 500+ > triangles per draw call, and probably not more than 100 draw calls per frame > - obviously these numbers are made up, and would need to be verified with > benchmarks, but they seem to be the sweet spot for me. of course i have - the calculations are easy. to calculate the number of quads take (screen_width/32)*(screen_height/ 32)*1.15 (1.15 being the factor that adds the average number of map objects per tile) when zooming out the tile size is not 32 but 24 or 16 respectively. so on my 1920x1200 resolution i draw 10k gl_quads when fully zoomed out. but tests show that this isnt the limiting factor. actually this still draws quite fast especially on new gfx cards. the trouble comes in when i correctly order the map objects with OrderedGroups. then up to 150 gl state changes are done (in contrast to only X state changes (X being the number of textures) when not ordering anything) and this is what kills my gfx and even the newer one as i presume that this is about the costly ctypes calls. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to pyglet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
