Ulrich Weigand wrote:
> To screen emulation specifically: whether we do it
> asynchronously using signals or a thread is really
> no difference as to performance on UP machines.
> (The only difference is that by using sched_yield you tie
> yourself to the host OSes scheduler quantum length, while
> using a timer you can select the update frequency yourself.)
I don't know... if you use the timer, you automatically
have an upper bound on your performance. OTOH,
using a separate thread will make the update quality
vary with the system load.
> Using synchronous updates instead of async ones may be
> even slower: there can be a *lot* of accesses to the video
> memory, and causing a full VM switch for every byte written
> might well be much slower than just reading the whole
> thing say 50 times a second.
Uh... hang on. I never mentioned this. What are you
referring to, exactly ? I said
(1) that you can map in the framebuffer. I didn't mean
map it in read-only, or something like that !!!
I meant it exactly as I said it -- you can mmap()
the framebuffer from /dev/mem, and write directly
to it, just like XFree86 does (that does assume
you want full-screen --- DOSEMU works that way.
As a matter of fact, DOSEMU video system is mostly
modified from the XFree86 video driver sources.)
You can then go on to map this real, *physical*
framebuffer into the guest, so the guest will
also have direct access to the system framebuffer.
X DGA works in a similar way, only you map in
the X's graphics buffer in stead of the physical
framebuffer.
(2) that you can use the dirty bit to check, whether
the guest wrote to the framebuffer memory.
There's no reason that this should imply mapping
the FB read-only... to the contrary, it avoids it.
-- Ramon
