[Scummvm-devel] ATTN porters: updateScreen() OSystem method

[Eugene Sandulenko]

On Tue, 18 Apr 2006 11:29:12 +0200
Marcus Comstedt <marcus at mc.pp.se> wrote:

> 
> Eugene Sandulenko <sev at scummvm.org> writes:
> 
> >> Simply updating the screen at the end of pollEvent is probably
> >> _not_ a good idea.
> > To bring this topic back to life.
> >
> > It seems that at least several backends do not follow what is
> > described in common/system.h, namely this:
> >
> >         /** Update the dirty areas of the screen. */
> >         virtual void updateScreen() = 0;
> >
> > I.e. any call to updateScreen() condition-less updates the screen.
> > What would be proper is to update it only when any of following
> > OSystem calls were invoked:
> 
> This is a little beside the point made previously.  Does moving the
> mouse make (an area of) the screen "dirty"?  If so the screen would be
> redrawn every time anyway as long as you keep moving the mouse, and so
> nothing would be solved.  If not, then updating the screen more often
> would not give smoother mouse movement.
After some rethought, I realized that in fact all previous mail should
be narrowed down to something like this:

Expect updateScreen() to be called at arbitrary rate, say, 200 calls/s.

Thus if your backend cannot handle that framerate, implement frame skip
with something like this:

  updateScreen() {
      uint32 newTime = _system->getMillis();
      if (newTime - _oldTime < 1000 / MAX_FPS)
          return;

      _oldTime = newTime;

       // do actual screen update
  }

Ideally every backend can implement this, SDL included.

This is IMHO simple and does not force backend to use some particular
dirty rect handling, i.e. DC backend can flip whole screen at 60fps.

The goal here is that frontend can call updateScreen() at any time
without fear of overloading low end hardware and still be sure that all
changes are visible.


Eugene