Jeroen Janssen wrote:
>
> > The VM should not waste CPU-ressources on scanning this buffer for
> > changes.
> >
> > There should be an mechanism to tell the host-code which parts of the
> > frame-buffer have to be redrawn.
>
> I first want to do "worst case scenario" (when all pixels need to be
> drawn)... depending on the guest OS display driver abilities, it might
> also be possible to have a list with "dirty" areas that need to be
> redrawn, but this stands/fails with the ability to detect wich areas are
> "dirty".
I guess an idea here that's already been covered is to write protect
the virtual screen buffer to assist detection of changed data in a
framebuffer. The system page size's likely to be pretty coarse, but
could probably still save a lot of scanning time by trapping the
exception, putting that block into a search list and unlocking the
page, something I've mucked about with on another architecture.
We have more context at to work with than the routines down the line
so it'd be nice to present concise updates to (say) a framebuffer
being drawn in a window in X.
In the ideal situation (full screen operation) we can ignore the above
and try to just give direct access to the real framebuffer. I guess
it'll also become less relevant as we implement various graphics
acceleration techniques later on.
As far as guest OS windoze drivers goes, I'll take a WMA driver with
my fries please :) Seriously, that way with one lump of code we are
helping both those who want to play their favourite games under 9X,
and people like me who want to dump Win2K and move to Linux but can't
'cos we need to compile, test and support our Delphi apps under
Windoze. Not that I'm being specific or anything :-)
- Andrew
--
Andrew Stewart Cave Rock Software
[EMAIL PROTECTED] phone +64 3 3664242
