Hi Alex, Thanks for the help.
> > I am Using Pyglet to browse (interactively) the contents of an Object > > database such as ZODB. > > Cool! Be great if you can post a screenshot/link when it's going. I will certainly do that! > Thanks, that demonstrates the problem fine. The performance problem > stems from (as you guessed) assigning a long string to the Text > object. When you do this, it needs to do a non-trivial amount of > work to re-layout the text... moreso if you have enabled word- > wrapping (which you have, by specifying a width). Luckily, your case > should be very simple to optimise... > > * At the moment you're not actually getting any word-wrapping > behaviour because there are no spaces in the data. If this is not > just an artifact of the example program you've given, leave out the > width= keyword so it knows not to bother trying to wordwrap. > * Very few of the 160,000 characters you are asking pyglet to layout > will actually be visible, unless you have a gigantic monitor the > world has never seen. See if you can trim this down to a reasonable > size before assigning it. Sure, my only reason for using such long strings was to test the limits of the text renderer. actually, the string representation of some of the objetcs in an object database can be quite large. The best way to handle this, i think, would be to write an object parser which would return a sensible string representation of any object. > * If you don't want to preemptively trim the string, you could > subclass Text and implement some clipping so that layout stops when > the known window size is exceeded. Maybe I could write a text scroller a la "star wars" ;-) > * In this example, you're changing the text every frame. I can't > imagine any use-case in which this will actually be useful... That allows me to see that he string is actually being repainted in this test. But in my Data base browser I want text to be updated as fast as possible in response to keyboard/mouse events. > layout is performed lazily only when text is changed, so if your data only > changes every 100ms or more, most frames can be drawn quickly without > having to re-layout the text. Check out the clock.schedule_interval > function for a possibly-useful hook for this. > > If you're still unhappy with this performance, consider writing your > own layout procedure. There are many optimisations you could make > based on the specific nature of what you're doing (for example, using > a monospaced font would speed things up, or knowing the word breaks > in advance). OK, i will think about these things... > > If you find that you get layout done quickly but due to the amount of > text you're rendering performance is still sub-optimal, wrap the Text > in a GL display list, or subclass and use vertex buffer objects (this > is on my TODO... eventually) instead of system memory arrays. This goes a bit beyond my knowledge of OpenGL, but perhaps it's time to learn some more... ;-) > One final note from your code which you may already have been aware > of: the clock.set_fps_limit() has no effect unless you're calling > clock.tick() every frame. Thanks for the tip! Is this documented in the programming guide? thanks! Flávio --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
