[Scummvm-devel] Framebuffer
Kostas Nakos
knakos at phys.uoa.gr
Sun Jun 17 10:50:44 CEST 2007
Max Horn wrote:
> * A more refined API to tell the backend about "dirty" areas might be
> helpful. Or not. I can't really judge whether ports would benefit.
> For desktop machines, though, it seems that on modern machines, esp.
> when using expensive scalers, it can be much more efficient to have a
> copy of the previous frame around, then do a pixel-by-pixel check to
> compute all pixels that need to be updated, and then update
> everything at once. This might be totally different for low end
> devices, though. I am reluctant to implement anything in this area
> without knowing whether there are any benefits, though. Hence,
> porters, if you can think of potential improvements (like a
> 'OSystem::markRectAsDirty' method), tell me, and promise to work with
> me on testing the theory :-).
My experience in WinCE has proved that implementing a dirty update
scheme makes the difference between real-time and slow performance, on
more than the average case. The reason is that palette translations +
scaling turn out to be rather expensive, so the less performed the
better (I have to convert from 8pp to 16bpp 565 or 555). Note that the
current draw path for wince scummvm is: 8bpp->(dirty areas)16bpp->(dirty
areas)scaler->(dirty areas)copy to device screen with rotation.
I other wince projects, I've been doing dirty updates using two schemes
which differ slightly between them but they boil down to comparing
against the previous frame in either batches of 4 (unit32 comparison) or
8 pixels (more elaborate & complicated scheme), then if they're
different the new pixels get translated, scaled etc.
There are obviously 2 ways dirty areas get generated in scummvm: 1) An
engine knows which areas are being repainted through the logic of the
scripts, 2) The frame is compared against the previous one for changes.
I gather that (1) is extremely difficult to do universally so we're left
with (2). Further I'm not sure it's worth the trouble to go around
collating areas of changed pixels to rects, instead of just scanning the
frame and directly updating pixels. But since we've already got a
rect-based thing going which performs very nicely, maybe we can stick
with it. Also, I'm not sure how/if we can have rect-based updates &
pixel based updates at the same time.
So to sum up, we definitively need a dirty update scheme. The specifics
of it are not clear to me right now, but maybe we should look in the
direction of somehow extending what's already in place.
Best,
Kostas
More information about the Scummvm-devel
mailing list