Re: [MiNT] FVDI/XBIOS (was Re: XaAES sources for FreeMiNT 1.16.3)

[Johan Klockars <johan@klockars.net>]

> A network VDI would work - as long as the apps doesn't access the screen
> directly.

And it would even work quite well, assuming you have a half-decent
network. After all, the Eclipse/RageII is quite snappy for most
things, even in 32 bit mode, and that is limited by the Falcon bus to
~4 Mbyte/s or so.

It shouldn't be hard to write an fVDI driver that passes drawing
operations via a TCP socket, or similar, and the remote drawing engine
could be based on the code from ARAnyM.

Unless you have a really fast network (or don't want to use highed bit
depths), however, you would want to do the kind of graphics RAM (VDI
server in this case) caching that the RageII driver does. Blitting
images back and forth (such as for icons and background saves) can be
really expensive.

Unfortunately, that kind of caching will never work 100% with the
current design of the VDI (it can only guess as to which blits will
not need to go to RAM, and which blits from RAM that use the same data
as last time). A few simple changes, which could relatively easily be
incorporated into programs that have the source code available, would
fix that, however.

> However, I think that a decent VNC server can be implemented with some
> additional support from the VDI (or by playing dirty and hook into the VDI
> trap). If you can monitor all drawing functions and clip the coordinates
> with the clip rectangle, you will easily be able to work out which parts of

It would indeed be "simple" to do this with VDI support, but the
"dirty way" you are suggesting would be nearly impossible to get
right. For many VDI operations, the dirty rectangles are easy to
figure out, but that does not apply to all of them.

> to a memory block. If you don't specify a source address the screen will be
> used as source, so you don't have to know the screen address at all.

People not realizing that caused me quite a bit of trouble with fVDI...

/Johan