Re: Animation/Python/PyGames vs battery charge
Hi I suspect that the best thing you can do to reduce power is to make sure that your game doesn't do anything when it isn't the frontmost thing on the screen. I.e. if the window that you're drawing in is totally obscured, then don't run ANYTHING -- no game animations, but also no background world-simulating stuff, and little or no network activity. Resume activity once the user brings your game to the front again. Don't wake up periodically and do anything; be sure to do NOTHING. Ensuring this background-idle behavior will not only allow the activity that's frontmost to get 100% of the CPU cycles. It will also allow the XO to suspend and power down if that frontmost activity goes idle. (If you're chewing up CPU in the background, the system won't auto-suspend.) Maybe sugar could suspend those activities which are in the background so the activities don't have to worry about it. Also it would be fool proof. -- Rózsás Gödény ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Animation/Python/PyGames vs battery charge
The stuff I am writing is interactive animation. That is to say the activity responses are animated. There may be intentional delays while the child is given time to consider a response. If the delay is long the activity may give additional information or encouragement to facilitate the child's response. I was looking for a way to minimize energy consumption while waiting for the child to respond. On Wednesday 30 January 2008 00:04:27 Rózsás Gödény wrote: Hi I suspect that the best thing you can do to reduce power is to make sure that your game doesn't do anything when it isn't the frontmost thing on the screen. I.e. if the window that you're drawing in is totally obscured, then don't run ANYTHING -- no game animations, but also no background world-simulating stuff, and little or no network activity. Resume activity once the user brings your game to the front again. Don't wake up periodically and do anything; be sure to do NOTHING. Ensuring this background-idle behavior will not only allow the activity that's frontmost to get 100% of the CPU cycles. It will also allow the XO to suspend and power down if that frontmost activity goes idle. (If you're chewing up CPU in the background, the system won't auto-suspend.) Maybe sugar could suspend those activities which are in the background so the activities don't have to worry about it. Also it would be fool proof. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Animation/Python/PyGames vs battery charge
I am trying to preserve as much battery energy as I can. So I am setting a specific frame rate and sleeping beyond what it takes to maintain that frame rate. Do you think this will actually reduce the drain on the XO battery? Sleeping for a small fraction of a second (e.g. 1/20th of a second or less) will reduce the CPU's power drain slightly, when the Linux scheduler executes a Halt instruction. But it won't allow the XO's very aggressive powering down of the whole CPU chip. That's because it currently takes the OLPC OS almost a whole second to power down or power up the CPU chip. (This, in turn, is partly caused by the hardware being designed to do that for Windows when the user hits the manual Suspend button, and partly by inefficiencies in the kernel drivers that will soon be addressed.) The system's design goal is to do this in a tenth or a second or so. Thus any frame rate above about 8 Hz is going to make suspending impossible while your game is running, even with the best possible auto-suspend software running in today's hardware. I suspect that the best thing you can do to reduce power is to make sure that your game doesn't do anything when it isn't the frontmost thing on the screen. I.e. if the window that you're drawing in is totally obscured, then don't run ANYTHING -- no game animations, but also no background world-simulating stuff, and little or no network activity. Resume activity once the user brings your game to the front again. Don't wake up periodically and do anything; be sure to do NOTHING. Ensuring this background-idle behavior will not only allow the activity that's frontmost to get 100% of the CPU cycles. It will also allow the XO to suspend and power down if that frontmost activity goes idle. (If you're chewing up CPU in the background, the system won't auto-suspend.) (To test this, log in to your XO via ssh from another machine, and run strace -p N to watch your game do system calls. This will verify for you that no system calls are happening while the game is not visible. If strace shows system calls happening, you can get out of strace with Ctrl-C and run gdb to see why those calls are happening. To login via ssh you'll need to set a password for root or olpc first.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Animation/Python/PyGames vs battery charge
I have set up some test animation code. Normally games try to take all the cycles they can get. I am trying to preserve as much battery energy as I can. So I am setting a specific frame rate and sleeping beyond what it takes to maintain that frame rate. Do you think this will actually reduce the drain on the XO battery? In other words What does the XO do when apps sleep? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Animation/Python/PyGames vs battery charge
Noah Kantrowitz wrote: Kent Loobey wrote: I have set up some test animation code. Normally games try to take all the cycles they can get. I am trying to preserve as much battery energy as I can. So I am setting a specific frame rate and sleeping beyond what it takes to maintain that frame rate. Do you think this will actually reduce the drain on the XO battery? In other words What does the XO do when apps sleep? If SDL is actually using a real timed sleep, it would help, but I don't think it does. This is often too inaccurate for games, so we may need to look at that ourselves. Because pygame is polling driven (instead of using async callbacks like GTK) it is unlikely that it will ever get as nice a battery life as GTK-based activities. There are two types of sleep in Pygame, one is: pygame.time.wait( milliseconds ) which does a process sleep. The other is: pygame.time.delay( milliseconds ) which does a busy-loop to provide accurate time-keeping. OLPCGames also now has a function which combines wait with a time-based sleep state where the program is completely suspended if there are no events for a given period. The same is true of Pippy's (independent) wrapper. That said, lots of games, particularly ones which are simulation based, may need to run all the time. The XO is also *not* currently (AFAIK) doing aggressive suspend. That is, while we would like to get to the point where the machine can suspend and resume in 10ms range, it currently takes too long to shut down between frames of a game. That is, while eventually micro-sleep may show up, AFAIK we don't yet have support for it on the laptop, so the processor is likely running at 100% power (even if in a busy loop in the kernel) (AFAIK there is no frequency scaling available in the processor). We might get some minimal benefit from having less load, but if we're waking up 10 or 15 times a second we're not going to see the kind of power benefits we'd see with multi-second or multi-minute suspending. We still want to have the games waiting when they are not needed. Eventually we hope to get aggressive suspend such that between frames we can go to sleep, but until then the power benefits are in allowing other processes to run, and in shutting down the game entirely after a period of inactivity. HTH, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
