[openMSX-devel] Responsiveness of control clients when openMSX is paused

[Maarten t. H. <ma...@tr...>]

Hi,

Edwin found that the responsiveness of openMSX handling input from the control 
clients (the debugger, in this case) is a lot better when openMSX is running 
compared to when openMSX is paused.

The reason for this is the current Reactor loop:

  while (running) {
      bool blocked = blockedCounter > 0;
      if (!blocked) blocked = !motherBoard.execute();
      if (blocked) {
          display.repaint();
          Timer::sleep(100 * 1000);
          motherBoard.getScheduler().doPoll();
          // TODO: Make Scheduler only responsible for events inside the MSX.
          //       All other events should be handled by the Reactor.
          scheduler.schedule(scheduler.getCurrentTime());
      }
  }

This means that when openMSX is paused (blocked) the frame rate goes to a 
fixed 10 FPS and the scheduler also runs 10 times per second. Since commands 
must be executed by the main thread, command execution goes through the 
Scheduler. This means a control client will have to wait up to 100ms before 
openMSX even sees the command that was sent.

Options to solve this:
1. Quick hack:
   reduce sleep amount
   drawback: higher CPU use
   drawback: repaints will slow down the loop, so responsiveness suffers
2. Clean:
   let CliConnection::execute call the Reactor iso Scheduler
   let Reactor wake up from sleeping when new events are registered
   one of those events is the repaint event, which is generated by a timer
   (we don't want to repaint on every event, because then control client would
   still be slow)
3. Cleaner:
   like 2, but without a timer
   so repaints only happen when something actually changes on the screen
   drawback: if repaint event is not sent, new state will not be visible
             (we have to be careful to always send repaint events when
             something on the screen changes)
   advantage: minimum CPU use

I want to implement option 2 first, since it solves the responsiveness issue, 
even though the CPU use is still slightly higher than needed (but not all 
that high in absolute terms). Because option 3 is a refinement of option 2, 
it is useful to implement 2 even if we go for 3 eventually.

Bye,
		Maarten