After doing some tests with the new threaded system, I came to the conclusion that the overhead of the thread system in python is pushing it, especially on the xo laptop. The system wasn't even using threads correctly as it was using global locks over the event and display loops. This was to prevent the display from being changed during a draw cycle. Without the locks you would get some interesting phantom elements on screen between frames. This wouldn't be so bad except the drawing takes a noticeable amount of time.
To fix this, I decided to go back to a modified version of the event driven loop (ticket 36). It is similar to the original engine in the fact the drawing is taken care of in the event loop. The major difference is that the event loop no longer blocks for events. Instead events are drawn only when the even queue sends a NOEVENT signal and only if the dirty flag is set or the game is set to animation mode. This new animation mode forces it to draw every time it gets the NOEVENT signal.
This fixes a few problems with the old system. The old system would require a timer for animation. When the timer fired to wake up the blocking event call, it would be fired to every event callback registered. This also caused a problem if your animation timer was too fast, it would fill the event queue adding animation events faster then they could be eaten up which would slow the system down.
It also takes the idea of the threading system into account. I was using global locks to prevent the system from clashing, now that it waits for the queue to be empty, it then completes a draw cycle and hands control over to the event loop again.