[Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.

laurent bernabe laurent.bernabe at gmail.com
Tue Oct 1 04:34:54 EDT 2013


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 <quozl at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20131001/c40f4bad/attachment.html>


More information about the Sugar-devel mailing list