Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
Yes, in the commits of the Tuesday October 01 2013. 2013/10/2 James Cameron qu...@laptop.org I see nothing new, did you push? On Tue, Oct 01, 2013 at 01:20:57PM +0200, laurent bernabe wrote: Thanks for these patch : I've applied all and commited them. I must admit I am yet far from good practises. 2013/10/1 James Cameron qu...@laptop.org On Tue, Oct 01, 2013 at 10:34:54AM +0200, laurent bernabe wrote: But I don't think I can avoid repainting all screen at each frame, as the balls move, so according to me, the performance gained this way, in the case of my application, won't be that high. Maybe, I am wrong. Yes, you're wrong. ;-) The performance gain is of the order of six times. Using top in 20 second sample period, the CPU usage dropped from 30% to 5%, just for the game process. There was a similar drop for the X process, which is the display handler. Please find attached five patches, which you can apply in order. The patches change the drawing functions to return sequences containing rectangles, which are then used by Pygame to update only the parts of the screen that need to be repainted. If the patches do not apply (git am), then perhaps you have made other changes, and I can rebase them. Push your changes and let me know. These changes will make the activity less energy intensive. -- James Cameron http://quozl.linux.org.au/ -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
Hello, thank you. In fact I could not push the changes, as (I think) Pootle has commited on it. 2013/10/1 James Cameron qu...@laptop.org Sorry, I was mentioning it for discussion only. Can you read patch files? The + means line added, the - means line removed. Alternatively, you might try saving the attached file and typing git am \ 0001-lower-frame-rate-and-ensure-frame-rate-is-enforced-d.patch But this might not work if your source has been edited or you have not pushed all changes since the hash that I mentioned. To answer your question exactly, no, the file need not have .patch in the name for you to use it with the patch command. On Tue, Oct 01, 2013 at 02:21:32AM +0200, laurent bernabe wrote: Thanks, the patch extension file must be .patch ? (I've no example on my disk and I forgot the git patch extension : so that I can paste your suggestion into gedit, and save it as a patch). Regards 2013/10/1 James Cameron qu...@laptop.org On Sat, Sep 28, 2013 at 01:42:50PM +0200, laurent bernabe wrote: But as the computer where I inserted the key was a very old one (it has an old AMD processor and it seems to me it has just 1GB of RAM), the animation where too slow : very slower than the result I got on my laptop (which has two processor at 2.19 Ghz). Apart this, it works, and I should submit the bundle to ASLO soon. I suggest fixing performance soon. On Sat, Sep 28, 2013 at 05:54:30PM +0200, laurent bernabe wrote: As my computer has 2*2.16Ghz processor, is it possible to configure sugar-build so that the speed is locked under 433 Mhz ? No. You raise an important issue though. You must tune your activity so that it works on the slowest hardware you support. The CPU clock isn't the only cause of slowness. Looking at your: git://git.sugarlabs.org/hittheballs/hittheballs in particular at hash 4533d1f2be64ef74d34129cf388919cfa36c8e91 In main_game.py you have chosen 40 frames per second for self._FPS. This is a very high rate for an OLPC XO-1. You should lower this number as much as possible until just before the game is unpleasant for a new user. The reason this number is important is that it determines the CPU processing required for display update between each opportunity to respond to input. The display update pipe is a work queue. If the update rate is too high, then the main_game.py will _pause_ briefly on line 223, and this pause will prevent main_game.py from responding quickly to keyboard or mouse events. Also, you must add a call to self._clock.tick(self._FPS) when game_state is not NORMAL, and while in show_menu, otherwise the display update pipe will be flooded, and you _will_ have delays and massive power use, shorter battery time. If after doing the above the performance is still too slow, then a more advanced display update method is required. I use this method in the Netrek game client Gytha. The method is to maintain a list of rectangles that have been dirtied, and only update those rectangles instead of the whole canvas. (by the way, you should rename gpl-3.0.txt to COPYING, because that is the conventional name) Below is a patch showing some of the performance changes mentioned above: diff --git a/main_game.py b/main_game.py index 110ebf3..0e23fd9 100644 --- a/main_game.py +++ b/main_game.py @@ -60,7 +60,7 @@ class Game: return pygame.init() self._LEFT_BUTTON = 1 -self._FPS = 40 +self._FPS = 10 self._MENU_LEVELS_RECTS_Y_GAP = 30 self._MENU_LEVELS_RECTS_WIDTH = 345 self._MENU_LEVELS_RECTS_HEIGHT = 60 @@ -220,6 +220,8 @@ class Game: pygame.time.set_timer(USEREVENT + 2, 1000) while True: +while Gtk.events_pending(): +Gtk.main_iteration() pygame.display.update() self._screen.fill(self._GAME_BACKGROUND) paint_result_bar(result_bar, self._screen) @@ -228,9 +230,6 @@ class Game: for ball in the_balls: paint_ball(ball, self._screen) -while Gtk.events_pending(): -Gtk.main_iteration() - for event in pygame.event.get(): if event.type == QUIT: pygame.quit() @@ -253,7 +252,6 @@ class Game: game_state = GameState.WON else: game_state = GameState.LOST
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
I don't know if that is stopping you. If so, I suggest you git pull --rebase so that the Pootle changes will be merged with your repository, then if that goes well you can try git push again. On Tue, Oct 01, 2013 at 10:14:24AM +0200, laurent bernabe wrote: Hello, thank you. In fact I could not push the changes, as (I think) Pootle has commited on it. 2013/10/1 James Cameron qu...@laptop.org Sorry, I was mentioning it for discussion only. Can you read patch files? The + means line added, the - means line removed. Alternatively, you might try saving the attached file and typing git am \ 0001-lower-frame-rate-and-ensure-frame-rate-is-enforced-d.patch But this might not work if your source has been edited or you have not pushed all changes since the hash that I mentioned. To answer your question exactly, no, the file need not have .patch in the name for you to use it with the patch command. On Tue, Oct 01, 2013 at 02:21:32AM +0200, laurent bernabe wrote: Thanks, the patch extension file must be .patch ? (I've no example on my disk and I forgot the git patch extension : so that I can paste your suggestion into gedit, and save it as a patch). Regards 2013/10/1 James Cameron qu...@laptop.org On Sat, Sep 28, 2013 at 01:42:50PM +0200, laurent bernabe wrote: But as the computer where I inserted the key was a very old one (it has an old AMD processor and it seems to me it has just 1GB of RAM), the animation where too slow : very slower than the result I got on my laptop (which has two processor at 2.19 Ghz). Apart this, it works, and I should submit the bundle to ASLO soon. I suggest fixing performance soon. On Sat, Sep 28, 2013 at 05:54:30PM +0200, laurent bernabe wrote: As my computer has 2*2.16Ghz processor, is it possible to configure sugar-build so that the speed is locked under 433 Mhz ? No. You raise an important issue though. You must tune your activity so that it works on the slowest hardware you support. The CPU clock isn't the only cause of slowness. Looking at your: git://git.sugarlabs.org/hittheballs/hittheballs in particular at hash 4533d1f2be64ef74d34129cf388919cfa36c8e91 In main_game.py you have chosen 40 frames per second for self._FPS. This is a very high rate for an OLPC XO-1. You should lower this number as much as possible until just before the game is unpleasant for a new user. The reason this number is important is that it determines the CPU processing required for display update between each opportunity to respond to input. The display update pipe is a work queue. If the update rate is too high, then the main_game.py will _pause_ briefly on line 223, and this pause will prevent main_game.py from responding quickly to keyboard or mouse events. Also, you must add a call to self._clock.tick(self._FPS) when game_state is not NORMAL, and while in show_menu, otherwise the display update pipe will be flooded, and you _will_ have delays and massive power use, shorter battery time. If after doing the above the performance is still too slow, then a more advanced display update method is required. I use this method in the Netrek game client Gytha. The method is to maintain a list of rectangles that have been dirtied, and only update those rectangles instead of the whole canvas. (by the way, you should rename gpl-3.0.txt to COPYING, because that is the conventional name) Below is a patch showing some of the performance changes mentioned above: diff --git a/main_game.py b/main_game.py index 110ebf3..0e23fd9 100644 --- a/main_game.py +++ b/main_game.py @@ -60,7 +60,7 @@ class Game: return pygame.init() self._LEFT_BUTTON = 1 - self._FPS = 40 + self._FPS = 10 self._MENU_LEVELS_RECTS_Y_GAP = 30 self._MENU_LEVELS_RECTS_WIDTH = 345 self._MENU_LEVELS_RECTS_HEIGHT = 60 @@ -220,6 +220,8 @@ class Game: pygame.time.set_timer(USEREVENT + 2, 1000) while True: + while Gtk.events_pending(): + Gtk.main_iteration() pygame.display.update()
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
Thanks, It was that : I had to merge the Pootle changes. Now I could push the patch commit. I would like to give the french translation : must I register as a Pootle user ? Regards 2013/10/1 James Cameron qu...@laptop.org I don't know if that is stopping you. If so, I suggest you git pull --rebase so that the Pootle changes will be merged with your repository, then if that goes well you can try git push again. On Tue, Oct 01, 2013 at 10:14:24AM +0200, laurent bernabe wrote: Hello, thank you. In fact I could not push the changes, as (I think) Pootle has commited on it. 2013/10/1 James Cameron qu...@laptop.org Sorry, I was mentioning it for discussion only. Can you read patch files? The + means line added, the - means line removed. Alternatively, you might try saving the attached file and typing git am \ 0001-lower-frame-rate-and-ensure-frame-rate-is-enforced-d.patch But this might not work if your source has been edited or you have not pushed all changes since the hash that I mentioned. To answer your question exactly, no, the file need not have .patch in the name for you to use it with the patch command. On Tue, Oct 01, 2013 at 02:21:32AM +0200, laurent bernabe wrote: Thanks, the patch extension file must be .patch ? (I've no example on my disk and I forgot the git patch extension : so that I can paste your suggestion into gedit, and save it as a patch). Regards 2013/10/1 James Cameron qu...@laptop.org On Sat, Sep 28, 2013 at 01:42:50PM +0200, laurent bernabe wrote: But as the computer where I inserted the key was a very old one (it has an old AMD processor and it seems to me it has just 1GB of RAM), the animation where too slow : very slower than the result I got on my laptop (which has two processor at 2.19 Ghz). Apart this, it works, and I should submit the bundle to ASLO soon. I suggest fixing performance soon. On Sat, Sep 28, 2013 at 05:54:30PM +0200, laurent bernabe wrote: As my computer has 2*2.16Ghz processor, is it possible to configure sugar-build so that the speed is locked under 433 Mhz ? No. You raise an important issue though. You must tune your activity so that it works on the slowest hardware you support. The CPU clock isn't the only cause of slowness. Looking at your: git://git.sugarlabs.org/hittheballs/hittheballs in particular at hash 4533d1f2be64ef74d34129cf388919cfa36c8e91 In main_game.py you have chosen 40 frames per second for self._FPS. This is a very high rate for an OLPC XO-1. You should lower this number as much as possible until just before the game is unpleasant for a new user. The reason this number is important is that it determines the CPU processing required for display update between each opportunity to respond to input. The display update pipe is a work queue. If the update rate is too high, then the main_game.py will _pause_ briefly on line 223, and this pause will prevent main_game.py from responding quickly to keyboard or mouse events. Also, you must add a call to self._clock.tick(self._FPS) when game_state is not NORMAL, and while in show_menu, otherwise the display update pipe will be flooded, and you _will_ have delays and massive power use, shorter battery time. If after doing the above the performance is still too slow, then a more advanced display update method is required. I use this method in the Netrek game client Gytha. The method is to maintain a list of rectangles that have been dirtied, and only update those rectangles instead of the whole canvas. (by the way, you should rename gpl-3.0.txt to COPYING, because that is the conventional name) Below is a patch showing some of the performance changes mentioned above: diff --git a/main_game.py b/main_game.py index 110ebf3..0e23fd9 100644 --- a/main_game.py +++ b/main_game.py @@ -60,7 +60,7 @@ class Game: return pygame.init() self._LEFT_BUTTON = 1 -self._FPS = 40 +self._FPS = 10 self._MENU_LEVELS_RECTS_Y_GAP = 30 self._MENU_LEVELS_RECTS_WIDTH = 345 self._MENU_LEVELS_RECTS_HEIGHT = 60
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
Sorry, I'm one of those monolinguists, so I've no idea. Chris Leonard can advise. On Tue, Oct 01, 2013 at 10:25:58AM +0200, laurent bernabe wrote: Thanks, It was that : I had to merge the Pootle changes. Now I could push the patch commit. I would like to give the french translation : must I register as a Pootle user ? Regards 2013/10/1 James Cameron qu...@laptop.org I don't know if that is stopping you. If so, I suggest you git pull --rebase so that the Pootle changes will be merged with your repository, then if that goes well you can try git push again. On Tue, Oct 01, 2013 at 10:14:24AM +0200, laurent bernabe wrote: Hello, thank you. In fact I could not push the changes, as (I think) Pootle has commited on it. 2013/10/1 James Cameron qu...@laptop.org Sorry, I was mentioning it for discussion only. Can you read patch files? The + means line added, the - means line removed. Alternatively, you might try saving the attached file and typing git am \ 0001-lower-frame-rate-and-ensure-frame-rate-is-enforced-d.patch But this might not work if your source has been edited or you have not pushed all changes since the hash that I mentioned. To answer your question exactly, no, the file need not have .patch in the name for you to use it with the patch command. On Tue, Oct 01, 2013 at 02:21:32AM +0200, laurent bernabe wrote: Thanks, the patch extension file must be .patch ? (I've no example on my disk and I forgot the git patch extension : so that I can paste your suggestion into gedit, and save it as a patch). Regards 2013/10/1 James Cameron qu...@laptop.org On Sat, Sep 28, 2013 at 01:42:50PM +0200, laurent bernabe wrote: But as the computer where I inserted the key was a very old one (it has an old AMD processor and it seems to me it has just 1GB of RAM), the animation where too slow : very slower than the result I got on my laptop (which has two processor at 2.19 Ghz). Apart this, it works, and I should submit the bundle to ASLO soon. I suggest fixing performance soon. On Sat, Sep 28, 2013 at 05:54:30PM +0200, laurent bernabe wrote: As my computer has 2*2.16Ghz processor, is it possible to configure sugar-build so that the speed is locked under 433 Mhz ? No. You raise an important issue though. You must tune your activity so that it works on the slowest hardware you support. The CPU clock isn't the only cause of slowness. Looking at your: git://git.sugarlabs.org/hittheballs/hittheballs in particular at hash 4533d1f2be64ef74d34129cf388919cfa36c8e91 In main_game.py you have chosen 40 frames per second for self._FPS. This is a very high rate for an OLPC XO-1. You should lower this number as much as possible until just before the game is unpleasant for a new user. The reason this number is important is that it determines the CPU processing required for display update between each opportunity to respond to input. The display update pipe is a work queue. If the update rate is too high, then the main_game.py will _pause_ briefly on line 223, and this pause will prevent main_game.py from responding quickly to keyboard or mouse events. Also, you must add a call to self._clock.tick(self._FPS) when game_state is not NORMAL, and while in show_menu, otherwise the display update pipe will be flooded, and you _will_ have delays and massive power use, shorter battery time. If after doing the above the performance is still too slow, then a more advanced display update method is required. I use this method in the Netrek game client Gytha. The method is to maintain a list of rectangles that have been dirtied, and only update those rectangles instead of the whole canvas. (by the way, you should rename gpl-3.0.txt to COPYING, because that is
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
I've just renamed gpl3.txt to COPYING. But I don't think I can avoid repainting all screen at each frame, as the balls move, so according to me, the performance gained this way, in the case of my application, won't be that high. Maybe, I am wrong. Regards 2013/10/1 James Cameron qu...@laptop.org On Sat, Sep 28, 2013 at 01:42:50PM +0200, laurent bernabe wrote: But as the computer where I inserted the key was a very old one (it has an old AMD processor and it seems to me it has just 1GB of RAM), the animation where too slow : very slower than the result I got on my laptop (which has two processor at 2.19 Ghz). Apart this, it works, and I should submit the bundle to ASLO soon. I suggest fixing performance soon. On Sat, Sep 28, 2013 at 05:54:30PM +0200, laurent bernabe wrote: As my computer has 2*2.16Ghz processor, is it possible to configure sugar-build so that the speed is locked under 433 Mhz ? No. You raise an important issue though. You must tune your activity so that it works on the slowest hardware you support. The CPU clock isn't the only cause of slowness. Looking at your: git://git.sugarlabs.org/hittheballs/hittheballs in particular at hash 4533d1f2be64ef74d34129cf388919cfa36c8e91 In main_game.py you have chosen 40 frames per second for self._FPS. This is a very high rate for an OLPC XO-1. You should lower this number as much as possible until just before the game is unpleasant for a new user. The reason this number is important is that it determines the CPU processing required for display update between each opportunity to respond to input. The display update pipe is a work queue. If the update rate is too high, then the main_game.py will _pause_ briefly on line 223, and this pause will prevent main_game.py from responding quickly to keyboard or mouse events. Also, you must add a call to self._clock.tick(self._FPS) when game_state is not NORMAL, and while in show_menu, otherwise the display update pipe will be flooded, and you _will_ have delays and massive power use, shorter battery time. If after doing the above the performance is still too slow, then a more advanced display update method is required. I use this method in the Netrek game client Gytha. The method is to maintain a list of rectangles that have been dirtied, and only update those rectangles instead of the whole canvas. (by the way, you should rename gpl-3.0.txt to COPYING, because that is the conventional name) Below is a patch showing some of the performance changes mentioned above: diff --git a/main_game.py b/main_game.py index 110ebf3..0e23fd9 100644 --- a/main_game.py +++ b/main_game.py @@ -60,7 +60,7 @@ class Game: return pygame.init() self._LEFT_BUTTON = 1 -self._FPS = 40 +self._FPS = 10 self._MENU_LEVELS_RECTS_Y_GAP = 30 self._MENU_LEVELS_RECTS_WIDTH = 345 self._MENU_LEVELS_RECTS_HEIGHT = 60 @@ -220,6 +220,8 @@ class Game: pygame.time.set_timer(USEREVENT + 2, 1000) while True: +while Gtk.events_pending(): +Gtk.main_iteration() pygame.display.update() self._screen.fill(self._GAME_BACKGROUND) paint_result_bar(result_bar, self._screen) @@ -228,9 +230,6 @@ class Game: for ball in the_balls: paint_ball(ball, self._screen) -while Gtk.events_pending(): -Gtk.main_iteration() - for event in pygame.event.get(): if event.type == QUIT: pygame.quit() @@ -253,7 +252,6 @@ class Game: game_state = GameState.WON else: game_state = GameState.LOST -self._clock.tick(self._FPS) for ball in the_balls: ball.move() balls_collision.manage_colliding_balls(the_balls) @@ -270,9 +268,6 @@ class Game: self._RED) self._screen.blit(end_txt_surface, self._END_TXT_POS) -while Gtk.events_pending(): -Gtk.main_iteration() - for event in pygame.event.get(): if event.type == QUIT: pygame.quit() @@ -282,6 +277,7 @@ class Game: elif event.type == MOUSEBUTTONUP: if event.button == self._LEFT_BUTTON: return +self._clock.tick(self._FPS) def show_menu(self): @@ -324,3 +320,4 @@ class Game: self._play_game( 30, self._levels[selected_level_index]) +self._clock.tick(self._FPS) --
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
No problem : so I'll wait for an answer. 2013/10/1 James Cameron qu...@laptop.org Sorry, I'm one of those monolinguists, so I've no idea. Chris Leonard can advise. On Tue, Oct 01, 2013 at 10:25:58AM +0200, laurent bernabe wrote: Thanks, It was that : I had to merge the Pootle changes. Now I could push the patch commit. I would like to give the french translation : must I register as a Pootle user ? Regards 2013/10/1 James Cameron qu...@laptop.org I don't know if that is stopping you. If so, I suggest you git pull --rebase so that the Pootle changes will be merged with your repository, then if that goes well you can try git push again. On Tue, Oct 01, 2013 at 10:14:24AM +0200, laurent bernabe wrote: Hello, thank you. In fact I could not push the changes, as (I think) Pootle has commited on it. 2013/10/1 James Cameron qu...@laptop.org Sorry, I was mentioning it for discussion only. Can you read patch files? The + means line added, the - means line removed. Alternatively, you might try saving the attached file and typing git am \ 0001-lower-frame-rate-and-ensure-frame-rate-is-enforced-d.patch But this might not work if your source has been edited or you have not pushed all changes since the hash that I mentioned. To answer your question exactly, no, the file need not have .patch in the name for you to use it with the patch command. On Tue, Oct 01, 2013 at 02:21:32AM +0200, laurent bernabe wrote: Thanks, the patch extension file must be .patch ? (I've no example on my disk and I forgot the git patch extension : so that I can paste your suggestion into gedit, and save it as a patch). Regards 2013/10/1 James Cameron qu...@laptop.org On Sat, Sep 28, 2013 at 01:42:50PM +0200, laurent bernabe wrote: But as the computer where I inserted the key was a very old one (it has an old AMD processor and it seems to me it has just 1GB of RAM), the animation where too slow : very slower than the result I got on my laptop (which has two processor at 2.19 Ghz). Apart this, it works, and I should submit the bundle to ASLO soon. I suggest fixing performance soon. On Sat, Sep 28, 2013 at 05:54:30PM +0200, laurent bernabe wrote: As my computer has 2*2.16Ghz processor, is it possible to configure sugar-build so that the speed is locked under 433 Mhz ? No. You raise an important issue though. You must tune your activity so that it works on the slowest hardware you support. The CPU clock isn't the only cause of slowness. Looking at your: git://git.sugarlabs.org/hittheballs/hittheballs in particular at hash 4533d1f2be64ef74d34129cf388919cfa36c8e91 In main_game.py you have chosen 40 frames per second for self._FPS. This is a very high rate for an OLPC XO-1. You should lower this number as much as possible until just before the game is unpleasant for a new user. The reason this number is important is that it determines the CPU processing required for display update between each opportunity to respond to input. The display update pipe is a work queue. If the update rate is too high, then the main_game.py will _pause_ briefly on line 223, and this pause will prevent main_game.py from responding quickly to keyboard or mouse events. Also, you must add a call to self._clock.tick(self._FPS) when game_state is not NORMAL, and while in show_menu, otherwise the display update pipe will be flooded, and you _will_ have delays and massive power use, shorter battery time. If after doing the above the performance is still too slow, then a more advanced display update method is required. I use this method in the Netrek game client Gytha. The method is to maintain a list of rectangles that have
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
Yes, you need register as a pootle user to translate. Gonzalo On Tue, Oct 1, 2013 at 5:38 AM, laurent bernabe laurent.bern...@gmail.comwrote: No problem : so I'll wait for an answer. 2013/10/1 James Cameron qu...@laptop.org Sorry, I'm one of those monolinguists, so I've no idea. Chris Leonard can advise. On Tue, Oct 01, 2013 at 10:25:58AM +0200, laurent bernabe wrote: Thanks, It was that : I had to merge the Pootle changes. Now I could push the patch commit. I would like to give the french translation : must I register as a Pootle user ? Regards 2013/10/1 James Cameron qu...@laptop.org I don't know if that is stopping you. If so, I suggest you git pull --rebase so that the Pootle changes will be merged with your repository, then if that goes well you can try git push again. On Tue, Oct 01, 2013 at 10:14:24AM +0200, laurent bernabe wrote: Hello, thank you. In fact I could not push the changes, as (I think) Pootle has commited on it. 2013/10/1 James Cameron qu...@laptop.org Sorry, I was mentioning it for discussion only. Can you read patch files? The + means line added, the - means line removed. Alternatively, you might try saving the attached file and typing git am \ 0001-lower-frame-rate-and-ensure-frame-rate-is-enforced-d.patch But this might not work if your source has been edited or you have not pushed all changes since the hash that I mentioned. To answer your question exactly, no, the file need not have .patch in the name for you to use it with the patch command. On Tue, Oct 01, 2013 at 02:21:32AM +0200, laurent bernabe wrote: Thanks, the patch extension file must be .patch ? (I've no example on my disk and I forgot the git patch extension : so that I can paste your suggestion into gedit, and save it as a patch). Regards 2013/10/1 James Cameron qu...@laptop.org On Sat, Sep 28, 2013 at 01:42:50PM +0200, laurent bernabe wrote: But as the computer where I inserted the key was a very old one (it has an old AMD processor and it seems to me it has just 1GB of RAM), the animation where too slow : very slower than the result I got on my laptop (which has two processor at 2.19 Ghz). Apart this, it works, and I should submit the bundle to ASLO soon. I suggest fixing performance soon. On Sat, Sep 28, 2013 at 05:54:30PM +0200, laurent bernabe wrote: As my computer has 2*2.16Ghz processor, is it possible to configure sugar-build so that the speed is locked under 433 Mhz ? No. You raise an important issue though. You must tune your activity so that it works on the slowest hardware you support. The CPU clock isn't the only cause of slowness. Looking at your: git://git.sugarlabs.org/hittheballs/hittheballs in particular at hash 4533d1f2be64ef74d34129cf388919cfa36c8e91 In main_game.py you have chosen 40 frames per second for self._FPS. This is a very high rate for an OLPC XO-1. You should lower this number as much as possible until just before the game is unpleasant for a new user. The reason this number is important is that it determines the CPU processing required for display update between each opportunity to respond to input. The display update pipe is a work queue. If the update rate is too high, then the main_game.py will _pause_ briefly on line 223, and this pause will prevent main_game.py from responding quickly to keyboard or mouse events. Also, you must add a call to self._clock.tick(self._FPS) when game_state is not NORMAL, and while in show_menu, otherwise the display update pipe will be flooded, and you _will_ have delays and massive power use, shorter battery time. If after doing the above the performance is still too slow, then a more advanced display update method is required. I use this
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
On Tue, Oct 01, 2013 at 10:34:54AM +0200, laurent bernabe wrote: But I don't think I can avoid repainting all screen at each frame, as the balls move, so according to me, the performance gained this way, in the case of my application, won't be that high. Maybe, I am wrong. Yes, you're wrong. ;-) The performance gain is of the order of six times. Using top in 20 second sample period, the CPU usage dropped from 30% to 5%, just for the game process. There was a similar drop for the X process, which is the display handler. Please find attached five patches, which you can apply in order. The patches change the drawing functions to return sequences containing rectangles, which are then used by Pygame to update only the parts of the screen that need to be repainted. If the patches do not apply (git am), then perhaps you have made other changes, and I can rebase them. Push your changes and let me know. These changes will make the activity less energy intensive. -- James Cameron http://quozl.linux.org.au/ From cfaeaddb7b6699b14aefb38339954a4c7928e7bb Mon Sep 17 00:00:00 2001 From: James Cameron qu...@laptop.org Date: Tue, 1 Oct 2013 20:36:52 +1000 Subject: [PATCH 1/5] add test harness Add a main() function that can be used to test the activity without using Sugar, by typing this at a shell prompt: python main_game.py --- main_game.py | 8 1 file changed, 8 insertions(+) diff --git a/main_game.py b/main_game.py index 0e23fd9..411649a 100644 --- a/main_game.py +++ b/main_game.py @@ -321,3 +321,11 @@ class Game: 30, self._levels[selected_level_index]) self._clock.tick(self._FPS) +def main(): +pygame.init() +pygame.display.set_mode((0, 0), pygame.RESIZABLE) +game = Game() +game.show_menu() + +if __name__ == '__main__': +main() -- 1.8.1.2 From 91f9631543e8cbddac0ed312be08c9e0e41a0a5e Mon Sep 17 00:00:00 2001 From: James Cameron qu...@laptop.org Date: Tue, 1 Oct 2013 20:39:34 +1000 Subject: [PATCH 2/5] use fixed slower update rate in menus and end of round The high frame rate is necessary when playing a round of the game, but not as necessary while the menus are displayed. This reduces the CPU cycle cost of the menu from 40% to 5% on OLPC XO-1.5 measured with top at 20 second interval. --- main_game.py | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/main_game.py b/main_game.py index 411649a..2a976d9 100644 --- a/main_game.py +++ b/main_game.py @@ -255,6 +255,7 @@ class Game: for ball in the_balls: ball.move() balls_collision.manage_colliding_balls(the_balls) +self._clock.tick(self._FPS) else: paint_results(balls_area, the_balls, self._screen) # Blinks the status text. @@ -277,7 +278,7 @@ class Game: elif event.type == MOUSEBUTTONUP: if event.button == self._LEFT_BUTTON: return -self._clock.tick(self._FPS) +self._clock.tick(5) def show_menu(self): @@ -320,7 +321,8 @@ class Game: self._play_game( 30, self._levels[selected_level_index]) -self._clock.tick(self._FPS) +self._clock.tick(5) + def main(): pygame.init() pygame.display.set_mode((0, 0), pygame.RESIZABLE) -- 1.8.1.2 From f45fb2b84bfbfe37cbe2e2cd9a49f96f1fb13b38 Mon Sep 17 00:00:00 2001 From: James Cameron qu...@laptop.org Date: Tue, 1 Oct 2013 20:40:23 +1000 Subject: [PATCH 3/5] remove the loading screen, it was not visible --- main_game.py | 12 1 file changed, 12 deletions(-) diff --git a/main_game.py b/main_game.py index 2a976d9..d8ad3b0 100644 --- a/main_game.py +++ b/main_game.py @@ -174,19 +174,7 @@ class Game: = list of OperationConfig. -# Shows loading screen self._screen.fill(self._MENU_BACKGROUND) -loading_txt = _(Loading...) -loading_txt_surface = self._end_font.render( -loading_txt, -True, -self._BLUE -) -txt_size = self._end_font.size(loading_txt) -self._screen.blit(loading_txt_surface, ( -(self._size[0] - txt_size[0]) / 2, -(self._size[1] - txt_size[1]) / 2, -)) pygame.display.update() game_state = GameState.NORMAL -- 1.8.1.2 From 508fc1a16d014d99d8306b0a51c106926708add7 Mon Sep 17 00:00:00 2001 From: James Cameron qu...@laptop.org Date: Tue, 1 Oct 2013 20:41:22 +1000 Subject: [PATCH 4/5] return sequence of dirty rectangles for all drawing operations Every drawing operation is to return a sequence of rectangles that have been drawn on, for update optimisation. --- elements_painter.py | 44
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
Thanks, so I'll go to Pootle page (I will search it for a while) and register. Regards 2013/10/1 Gonzalo Odiard gonz...@laptop.org Yes, you need register as a pootle user to translate. Gonzalo On Tue, Oct 1, 2013 at 5:38 AM, laurent bernabe laurent.bern...@gmail.com wrote: No problem : so I'll wait for an answer. 2013/10/1 James Cameron qu...@laptop.org Sorry, I'm one of those monolinguists, so I've no idea. Chris Leonard can advise. On Tue, Oct 01, 2013 at 10:25:58AM +0200, laurent bernabe wrote: Thanks, It was that : I had to merge the Pootle changes. Now I could push the patch commit. I would like to give the french translation : must I register as a Pootle user ? Regards 2013/10/1 James Cameron qu...@laptop.org I don't know if that is stopping you. If so, I suggest you git pull --rebase so that the Pootle changes will be merged with your repository, then if that goes well you can try git push again. On Tue, Oct 01, 2013 at 10:14:24AM +0200, laurent bernabe wrote: Hello, thank you. In fact I could not push the changes, as (I think) Pootle has commited on it. 2013/10/1 James Cameron qu...@laptop.org Sorry, I was mentioning it for discussion only. Can you read patch files? The + means line added, the - means line removed. Alternatively, you might try saving the attached file and typing git am \ 0001-lower-frame-rate-and-ensure-frame-rate-is-enforced-d.patch But this might not work if your source has been edited or you have not pushed all changes since the hash that I mentioned. To answer your question exactly, no, the file need not have .patch in the name for you to use it with the patch command. On Tue, Oct 01, 2013 at 02:21:32AM +0200, laurent bernabe wrote: Thanks, the patch extension file must be .patch ? (I've no example on my disk and I forgot the git patch extension : so that I can paste your suggestion into gedit, and save it as a patch). Regards 2013/10/1 James Cameron qu...@laptop.org On Sat, Sep 28, 2013 at 01:42:50PM +0200, laurent bernabe wrote: But as the computer where I inserted the key was a very old one (it has an old AMD processor and it seems to me it has just 1GB of RAM), the animation where too slow : very slower than the result I got on my laptop (which has two processor at 2.19 Ghz). Apart this, it works, and I should submit the bundle to ASLO soon. I suggest fixing performance soon. On Sat, Sep 28, 2013 at 05:54:30PM +0200, laurent bernabe wrote: As my computer has 2*2.16Ghz processor, is it possible to configure sugar-build so that the speed is locked under 433 Mhz ? No. You raise an important issue though. You must tune your activity so that it works on the slowest hardware you support. The CPU clock isn't the only cause of slowness. Looking at your: git://git.sugarlabs.org/hittheballs/hittheballs in particular at hash 4533d1f2be64ef74d34129cf388919cfa36c8e91 In main_game.py you have chosen 40 frames per second for self._FPS. This is a very high rate for an OLPC XO-1. You should lower this number as much as possible until just before the game is unpleasant for a new user. The reason this number is important is that it determines the CPU processing required for display update between each opportunity to respond to input. The display update pipe is a work queue. If the update rate is too high, then the main_game.py will _pause_ briefly on line 223, and this pause will prevent main_game.py from responding quickly to keyboard or mouse events. Also, you must add a call to self._clock.tick(self._FPS) when game_state is not NORMAL, and while in show_menu, otherwise the display update pipe will be flooded, and you _will_ have delays and massive power use, shorter battery time. If after
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
Thanks for these patch : I've applied all and commited them. I must admit I am yet far from good practises. 2013/10/1 James Cameron qu...@laptop.org On Tue, Oct 01, 2013 at 10:34:54AM +0200, laurent bernabe wrote: But I don't think I can avoid repainting all screen at each frame, as the balls move, so according to me, the performance gained this way, in the case of my application, won't be that high. Maybe, I am wrong. Yes, you're wrong. ;-) The performance gain is of the order of six times. Using top in 20 second sample period, the CPU usage dropped from 30% to 5%, just for the game process. There was a similar drop for the X process, which is the display handler. Please find attached five patches, which you can apply in order. The patches change the drawing functions to return sequences containing rectangles, which are then used by Pygame to update only the parts of the screen that need to be repainted. If the patches do not apply (git am), then perhaps you have made other changes, and I can rebase them. Push your changes and let me know. These changes will make the activity less energy intensive. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
Yes, Chris Leonard can give you access. (Automatic account creation was removed due to spam) Gonzalo On Tue, Oct 1, 2013 at 8:27 AM, laurent bernabe laurent.bern...@gmail.comwrote: I've found : http://translate.sugarlabs.org/ But I did not find how to register : must a send a request to a given email ? Regards 2013/10/1 laurent bernabe laurent.bern...@gmail.com Thanks, so I'll go to Pootle page (I will search it for a while) and register. Regards ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
On Tue, Oct 1, 2013 at 4:25 AM, laurent bernabe laurent.bern...@gmail.com wrote: Thanks, It was that : I had to merge the Pootle changes. Now I could push the patch commit. I would like to give the french translation : must I register as a Pootle user ? Yes, please provide me with a preferred username and I will create a Pootle account for you. cjl ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
I see nothing new, did you push? On Tue, Oct 01, 2013 at 01:20:57PM +0200, laurent bernabe wrote: Thanks for these patch : I've applied all and commited them. I must admit I am yet far from good practises. 2013/10/1 James Cameron qu...@laptop.org On Tue, Oct 01, 2013 at 10:34:54AM +0200, laurent bernabe wrote: But I don't think I can avoid repainting all screen at each frame, as the balls move, so according to me, the performance gained this way, in the case of my application, won't be that high. Maybe, I am wrong. Yes, you're wrong. ;-) The performance gain is of the order of six times. Using top in 20 second sample period, the CPU usage dropped from 30% to 5%, just for the game process. There was a similar drop for the X process, which is the display handler. Please find attached five patches, which you can apply in order. The patches change the drawing functions to return sequences containing rectangles, which are then used by Pygame to update only the parts of the screen that need to be repainted. If the patches do not apply (git am), then perhaps you have made other changes, and I can rebase them. Push your changes and let me know. These changes will make the activity less energy intensive. -- James Cameron http://quozl.linux.org.au/ -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
On Sat, Sep 28, 2013 at 01:42:50PM +0200, laurent bernabe wrote: But as the computer where I inserted the key was a very old one (it has an old AMD processor and it seems to me it has just 1GB of RAM), the animation where too slow : very slower than the result I got on my laptop (which has two processor at 2.19 Ghz). Apart this, it works, and I should submit the bundle to ASLO soon. I suggest fixing performance soon. On Sat, Sep 28, 2013 at 05:54:30PM +0200, laurent bernabe wrote: As my computer has 2*2.16Ghz processor, is it possible to configure sugar-build so that the speed is locked under 433 Mhz ? No. You raise an important issue though. You must tune your activity so that it works on the slowest hardware you support. The CPU clock isn't the only cause of slowness. Looking at your: git://git.sugarlabs.org/hittheballs/hittheballs in particular at hash 4533d1f2be64ef74d34129cf388919cfa36c8e91 In main_game.py you have chosen 40 frames per second for self._FPS. This is a very high rate for an OLPC XO-1. You should lower this number as much as possible until just before the game is unpleasant for a new user. The reason this number is important is that it determines the CPU processing required for display update between each opportunity to respond to input. The display update pipe is a work queue. If the update rate is too high, then the main_game.py will _pause_ briefly on line 223, and this pause will prevent main_game.py from responding quickly to keyboard or mouse events. Also, you must add a call to self._clock.tick(self._FPS) when game_state is not NORMAL, and while in show_menu, otherwise the display update pipe will be flooded, and you _will_ have delays and massive power use, shorter battery time. If after doing the above the performance is still too slow, then a more advanced display update method is required. I use this method in the Netrek game client Gytha. The method is to maintain a list of rectangles that have been dirtied, and only update those rectangles instead of the whole canvas. (by the way, you should rename gpl-3.0.txt to COPYING, because that is the conventional name) Below is a patch showing some of the performance changes mentioned above: diff --git a/main_game.py b/main_game.py index 110ebf3..0e23fd9 100644 --- a/main_game.py +++ b/main_game.py @@ -60,7 +60,7 @@ class Game: return pygame.init() self._LEFT_BUTTON = 1 -self._FPS = 40 +self._FPS = 10 self._MENU_LEVELS_RECTS_Y_GAP = 30 self._MENU_LEVELS_RECTS_WIDTH = 345 self._MENU_LEVELS_RECTS_HEIGHT = 60 @@ -220,6 +220,8 @@ class Game: pygame.time.set_timer(USEREVENT + 2, 1000) while True: +while Gtk.events_pending(): +Gtk.main_iteration() pygame.display.update() self._screen.fill(self._GAME_BACKGROUND) paint_result_bar(result_bar, self._screen) @@ -228,9 +230,6 @@ class Game: for ball in the_balls: paint_ball(ball, self._screen) -while Gtk.events_pending(): -Gtk.main_iteration() - for event in pygame.event.get(): if event.type == QUIT: pygame.quit() @@ -253,7 +252,6 @@ class Game: game_state = GameState.WON else: game_state = GameState.LOST -self._clock.tick(self._FPS) for ball in the_balls: ball.move() balls_collision.manage_colliding_balls(the_balls) @@ -270,9 +268,6 @@ class Game: self._RED) self._screen.blit(end_txt_surface, self._END_TXT_POS) -while Gtk.events_pending(): -Gtk.main_iteration() - for event in pygame.event.get(): if event.type == QUIT: pygame.quit() @@ -282,6 +277,7 @@ class Game: elif event.type == MOUSEBUTTONUP: if event.button == self._LEFT_BUTTON: return +self._clock.tick(self._FPS) def show_menu(self): @@ -324,3 +320,4 @@ class Game: self._play_game( 30, self._levels[selected_level_index]) +self._clock.tick(self._FPS) -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
Thanks, the patch extension file must be .patch ? (I've no example on my disk and I forgot the git patch extension : so that I can paste your suggestion into gedit, and save it as a patch). Regards 2013/10/1 James Cameron qu...@laptop.org On Sat, Sep 28, 2013 at 01:42:50PM +0200, laurent bernabe wrote: But as the computer where I inserted the key was a very old one (it has an old AMD processor and it seems to me it has just 1GB of RAM), the animation where too slow : very slower than the result I got on my laptop (which has two processor at 2.19 Ghz). Apart this, it works, and I should submit the bundle to ASLO soon. I suggest fixing performance soon. On Sat, Sep 28, 2013 at 05:54:30PM +0200, laurent bernabe wrote: As my computer has 2*2.16Ghz processor, is it possible to configure sugar-build so that the speed is locked under 433 Mhz ? No. You raise an important issue though. You must tune your activity so that it works on the slowest hardware you support. The CPU clock isn't the only cause of slowness. Looking at your: git://git.sugarlabs.org/hittheballs/hittheballs in particular at hash 4533d1f2be64ef74d34129cf388919cfa36c8e91 In main_game.py you have chosen 40 frames per second for self._FPS. This is a very high rate for an OLPC XO-1. You should lower this number as much as possible until just before the game is unpleasant for a new user. The reason this number is important is that it determines the CPU processing required for display update between each opportunity to respond to input. The display update pipe is a work queue. If the update rate is too high, then the main_game.py will _pause_ briefly on line 223, and this pause will prevent main_game.py from responding quickly to keyboard or mouse events. Also, you must add a call to self._clock.tick(self._FPS) when game_state is not NORMAL, and while in show_menu, otherwise the display update pipe will be flooded, and you _will_ have delays and massive power use, shorter battery time. If after doing the above the performance is still too slow, then a more advanced display update method is required. I use this method in the Netrek game client Gytha. The method is to maintain a list of rectangles that have been dirtied, and only update those rectangles instead of the whole canvas. (by the way, you should rename gpl-3.0.txt to COPYING, because that is the conventional name) Below is a patch showing some of the performance changes mentioned above: diff --git a/main_game.py b/main_game.py index 110ebf3..0e23fd9 100644 --- a/main_game.py +++ b/main_game.py @@ -60,7 +60,7 @@ class Game: return pygame.init() self._LEFT_BUTTON = 1 -self._FPS = 40 +self._FPS = 10 self._MENU_LEVELS_RECTS_Y_GAP = 30 self._MENU_LEVELS_RECTS_WIDTH = 345 self._MENU_LEVELS_RECTS_HEIGHT = 60 @@ -220,6 +220,8 @@ class Game: pygame.time.set_timer(USEREVENT + 2, 1000) while True: +while Gtk.events_pending(): +Gtk.main_iteration() pygame.display.update() self._screen.fill(self._GAME_BACKGROUND) paint_result_bar(result_bar, self._screen) @@ -228,9 +230,6 @@ class Game: for ball in the_balls: paint_ball(ball, self._screen) -while Gtk.events_pending(): -Gtk.main_iteration() - for event in pygame.event.get(): if event.type == QUIT: pygame.quit() @@ -253,7 +252,6 @@ class Game: game_state = GameState.WON else: game_state = GameState.LOST -self._clock.tick(self._FPS) for ball in the_balls: ball.move() balls_collision.manage_colliding_balls(the_balls) @@ -270,9 +268,6 @@ class Game: self._RED) self._screen.blit(end_txt_surface, self._END_TXT_POS) -while Gtk.events_pending(): -Gtk.main_iteration() - for event in pygame.event.get(): if event.type == QUIT: pygame.quit() @@ -282,6 +277,7 @@ class Game: elif event.type == MOUSEBUTTONUP: if event.button == self._LEFT_BUTTON: return +self._clock.tick(self._FPS) def show_menu(self): @@ -324,3 +320,4 @@ class Game: self._play_game( 30, self._levels[selected_level_index]) +self._clock.tick(self._FPS) -- James Cameron http://quozl.linux.org.au/
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
Sorry, I was mentioning it for discussion only. Can you read patch files? The + means line added, the - means line removed. Alternatively, you might try saving the attached file and typing git am \ 0001-lower-frame-rate-and-ensure-frame-rate-is-enforced-d.patch But this might not work if your source has been edited or you have not pushed all changes since the hash that I mentioned. To answer your question exactly, no, the file need not have .patch in the name for you to use it with the patch command. On Tue, Oct 01, 2013 at 02:21:32AM +0200, laurent bernabe wrote: Thanks, the patch extension file must be .patch ? (I've no example on my disk and I forgot the git patch extension : so that I can paste your suggestion into gedit, and save it as a patch). Regards 2013/10/1 James Cameron qu...@laptop.org On Sat, Sep 28, 2013 at 01:42:50PM +0200, laurent bernabe wrote: But as the computer where I inserted the key was a very old one (it has an old AMD processor and it seems to me it has just 1GB of RAM), the animation where too slow : very slower than the result I got on my laptop (which has two processor at 2.19 Ghz). Apart this, it works, and I should submit the bundle to ASLO soon. I suggest fixing performance soon. On Sat, Sep 28, 2013 at 05:54:30PM +0200, laurent bernabe wrote: As my computer has 2*2.16Ghz processor, is it possible to configure sugar-build so that the speed is locked under 433 Mhz ? No. You raise an important issue though. You must tune your activity so that it works on the slowest hardware you support. The CPU clock isn't the only cause of slowness. Looking at your: git://git.sugarlabs.org/hittheballs/hittheballs in particular at hash 4533d1f2be64ef74d34129cf388919cfa36c8e91 In main_game.py you have chosen 40 frames per second for self._FPS. This is a very high rate for an OLPC XO-1. You should lower this number as much as possible until just before the game is unpleasant for a new user. The reason this number is important is that it determines the CPU processing required for display update between each opportunity to respond to input. The display update pipe is a work queue. If the update rate is too high, then the main_game.py will _pause_ briefly on line 223, and this pause will prevent main_game.py from responding quickly to keyboard or mouse events. Also, you must add a call to self._clock.tick(self._FPS) when game_state is not NORMAL, and while in show_menu, otherwise the display update pipe will be flooded, and you _will_ have delays and massive power use, shorter battery time. If after doing the above the performance is still too slow, then a more advanced display update method is required. I use this method in the Netrek game client Gytha. The method is to maintain a list of rectangles that have been dirtied, and only update those rectangles instead of the whole canvas. (by the way, you should rename gpl-3.0.txt to COPYING, because that is the conventional name) Below is a patch showing some of the performance changes mentioned above: diff --git a/main_game.py b/main_game.py index 110ebf3..0e23fd9 100644 --- a/main_game.py +++ b/main_game.py @@ -60,7 +60,7 @@ class Game: return pygame.init() self._LEFT_BUTTON = 1 - self._FPS = 40 + self._FPS = 10 self._MENU_LEVELS_RECTS_Y_GAP = 30 self._MENU_LEVELS_RECTS_WIDTH = 345 self._MENU_LEVELS_RECTS_HEIGHT = 60 @@ -220,6 +220,8 @@ class Game: pygame.time.set_timer(USEREVENT + 2, 1000) while True: + while Gtk.events_pending(): + Gtk.main_iteration() pygame.display.update() self._screen.fill(self._GAME_BACKGROUND) paint_result_bar(result_bar, self._screen) @@ -228,9 +230,6 @@ class Game: for ball in the_balls: paint_ball(ball, self._screen) - while Gtk.events_pending(): - Gtk.main_iteration() - for event in pygame.event.get(): if event.type == QUIT: pygame.quit() @@ -253,7 +252,6 @@ class Game: game_state = GameState.WON else: game_state = GameState.LOST - self._clock.tick(self._FPS) for ball in the_balls: ball.move() balls_collision.manage_colliding_balls(the_balls) @@ -270,9 +268,6 @@ class Game:
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
I managed to run my application bundle thanks to a Soas usb key (sugar 0.98.8), without installing the bundle. But as the computer where I inserted the key was a very old one (it has an old AMD processor and it seems to me it has just 1GB of RAM), the animation where too slow : very slower than the result I got on my laptop (which has two processor at 2.19 Ghz). Where can I find the standard OLPCs configs ? Just in order to have an idea for the speed application. Apart this, it works, and I should submit the bundle to ASLO soon. Regards. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
Yes, I think you will not have a problem. Please try and tell us. 2013/9/27 laurent bernabe laurent.bern...@gmail.com: Hi, As I developped my activity (HitTheBalls) under sugar-build 0.100, I am wondering if I can test the bundle with SOAS 0.98 (installing it on Virtual Box). I mean : does SOAS 0.98 relies on GTK3 ? what 0.100 features may prevent me from using it in 0.98 (I am conviced that I did not use any of these) ? Regards ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
Thanks, So I'll try with the SoaS v8 appliance for Virtual Box. I will report the success or failure, and possibly post bundle on ASLO. 2013/9/27 Manuel Quiñones ma...@laptop.org Yes, I think you will not have a problem. Please try and tell us. 2013/9/27 laurent bernabe laurent.bern...@gmail.com: Hi, As I developped my activity (HitTheBalls) under sugar-build 0.100, I am wondering if I can test the bundle with SOAS 0.98 (installing it on Virtual Box). I mean : does SOAS 0.98 relies on GTK3 ? what 0.100 features may prevent me from using it in 0.98 (I am conviced that I did not use any of these) ? Regards ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
