I'm almost done removing everything. I have some things left to do with the Window module still.
One thing did come to light when cleaning up the `clock` module. That is, the deprecated `set_fps_limit` API included a CPU busy-wait sleep method. It uses the standard OS to do it's rough sleep, then finishes up the remaining time with the busy-wait. This seems to be a pretty popular and accurate way of doing things. The current API pushes this waiting up the stack a bit into the `app` module. Rather than using a predetermined time for the next tick, it's dependent on whenever the next scheduled function is. The waiting (on Linux at least) is done while polling for new events. There might be a benefit in accuracy if we can also implement a busy-wait here. I'll have to give this some testing after the other work is done. On Sunday, December 17, 2017 at 9:29:08 AM UTC+9, Benjamin Moran wrote: > > Good idea. I've been making simple 1-sentence notes, but a proper writeup > would be nice. I can write something up once I'm finished. I'm thinking > maybe we can put that writeup in 1.4, and then pull in the changes in 1.5. > > > On Sunday, December 17, 2017 at 3:54:14 AM UTC+9, Rob wrote: >> >> Maybe we can add a page describing the upgrade steps? A simple mapping of >> old to new methods would suffice. >> >> Rob >> >> On 16 Dec 2017 14:02, "Benjamin Moran" <[email protected]> wrote: >> >>> It turns out the clock stuff wasn't all that difficult to pull out after >>> all. There was a decent amount of code removed there. >>> >>> One potential pain point for other libraries, is that the Window >>> "Platform" API is gone, having been replaced by methods in the canvas >>> module. Its very simple to switch to the new API, though, so it shouldn't >>> be an issue I hope. >>> >>> >>> On Monday, December 11, 2017 at 12:44:55 PM UTC+9, Benjamin Moran wrote: >>>> >>>> I've started pulling out these methods. One potential pain point is the >>>> old fps limiting functions from the clock module. There are a few >>>> references to this in other parts of the code base, but It's a good time >>>> to >>>> clean that up. >>>> -Ben >>>> >>>> On Monday, December 4, 2017 at 1:11:21 PM UTC+9, Benjamin Moran wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> This is a heads-up for everyone, especially for projects that are >>>>> making use of pyglet under the hood. In an effort to clean up the >>>>> codebase, I'm planning on removing most of the long deprecated methods >>>>> and >>>>> attributes from pyglet. Most of these have been deprecated for a few >>>>> releases (a year or more), so hopefully this won't cause too much >>>>> inconvenience. If anyone has any specific use case for deprecated >>>>> methods, please share them so that we can understand your need. >>>>> >>>>> There are a few deprecated methods/attributes in each module, so I'll >>>>> try to reply here with a list of what will be removed and the new way to >>>>> do >>>>> it. >>>>> For example, the *sprite.set_position(x, y)* method has been replaced >>>>> with a position attribute: >>>>> *sprite.position = x, y* >>>>> The upcoming 1.4 and 1.5 releases should hopefully be nice stable >>>>> releases with minimal cruft. >>>>> -Ben >>>>> >>>>> -- >>> 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. >>> >> -- 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.
