[Scummvm-devel] Dirty updates (Was: Framebuffer)
Max Horn
max at quendi.de
Sun Jun 17 21:17:27 CEST 2007
Hi Kostas, all,
you raise some very good points, although I think they are mostly
independent of the new framebuffer API.
What I really would like to see is somebody taking the current SDL
backend, creating a (temporarily) fork of it with a new rendering
pipeline implemented. One which gets rid of any dirty *rect* code and
instead implements proper auto dirty detection. That is, it keeps a
copy of the last rendered frame, then when updateScreen() is called
compares the current against the previous frame, and from this
automatically computes which pixels have to be updated. Then we could
run some performance comparisons; in particular it would be
interesting to learn how this affects CPU and RAM usage (of course
we'd need an extra buffer for the prev frame, but maybe we can save
in other places).
There are various details to consider for this, of course: Scalers
usually look at multiple input pixels to compute their output, so
whenever the autodirty code sees a changed pixel, it may also have to
dirty neighboring pixels. One way to do that w/o having to look at
all input pixels multiple times would be to compute a "dirty bitmap",
where for each pixel we keep a single "dirty" bit. Yes, more memory
again -- it's a speed vs. memory tradeoff, and I am not sure which
resource is more important in this case (and this might vary from
architecture to architecture), so some experiments might be necessary.
Also, one has to decide what is better: Keeping the prev frame before
or after the 8->16bit conversion. The former takes up less space and
potentially allows us to avoid converting certain pixels from 8 to 16
bit; OTOH, the latter approach gives us perfect "palette change
handling" for free (for example right now in games which do color
rotation, we always invalidate the whole screen in the SDL backend,
even if perhaps only a few pixels changed at all).
All in all the current rendering pipeline in the SDL backend is
rather convoluted and complex. It could certainly benefit from a
thorough overhaul. But this is not an easy task, given the number of
extra features one has to support: 8->16bit conversion, scaling,
aspect ratio correction (in place), separate mouse cursor scaling,
separate mouse palette, screen shaking, and of course the (GUI) overlay.
But automatic dirty updates might not be ideal for all backends, so
keeping an (optional) dirty rect API might still be a good idea
(right now we have this implicitly via copyRectToScreen/
copyRectToOverlay; in the future this *might* be phased out (nothing
has been decided yet, though), but then we could still keep a
markRectAsDirty() method (which on backends doing auto-dirtying would
simply do nothing).
The key thing to observe here is: How a backend implements screen
updates is entirely up to itself: Whether it always updates
everything, tries to keep track of dirty rects, or uses auto-
dirtying, or something else, frontend code should not care (except
that they should if possible provide dirty rect hints, at least as
long as we have backends that benefit from this). It would simplify
our APIs if we could just completely drop the dirty rect part,
though, but we can only do that if we don't hurt backends terminally
by this. In this sense it would be nice if porters could tell us
about their needs in this regard. I.e. if you are a porter and your
port needs dirty rect hints, please tell us!
Cheers,
Max
More information about the Scummvm-devel
mailing list