From mint-bounce@lists.fishpool.fi  Fri Dec 11 09:17:22 2009
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :date:message-id:subject:from:to:content-type;
        bh=Pp0dnb1HcqblnUKyohv9AAHW6EOIo/Rp557+hrUZpyc=;
        b=Z57OT0CAULhkArmC5BZKUvvUT0HQsBk1ZoEdpghs3RqKvLn0IHQilc0ADD2Yq/UTJz
         vxUL24qfNpyrmG5SNgvB26OQ/9VqGleld5I3Qx8YZb5iwULegxNxzI2y25klLBkzYvwz
         tHH0TGVTPqEPxvKsYq74L79b5CQdhbKGOoLWA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=IVFORTN4d9Piu6HsZAb1VaBxVl5cLGci1AOEK1WEKZLC3SYlAmnILPDHfRD9mweUgl
         Uy0RykbYoxP684q4KB4MKEfFklTh89o7HlSZA6xS6qRVluvljAb3tP1rFK05YS2qnzSz
         aCDYc8cZG0rmZ8ikvvDlhrL8E2QQGtWuVCLHM=
MIME-Version: 1.0
In-Reply-To: <fbbaf0fb0912110326s4666b41pa808491cc65fb74f@mail.gmail.com>
References: <C746A7AC.18DD9%atari@bright.net>
	 <4B214DD8.1090705@atari-source.org> <4B215AB1.1010401@online.no>
	 <fbbaf0fb0912110326s4666b41pa808491cc65fb74f@mail.gmail.com>
Date: Sat, 12 Dec 2009 01:14:12 +1100
Message-ID: <11a6f2b10912110614j1da84a1cla7756ef42d5a1ece@mail.gmail.com>
Subject: Re: [MiNT] FVDI/XBIOS (was Re: XaAES sources for FreeMiNT 1.16.3)
From: Paul Wratt <paul.wratt@gmail.com>
To: mint <mint@lists.fishpool.fi>
Content-Type: text/plain; charset=ISO-8859-1
X-ecartis-version: Ecartis v1.0.0
Sender: mint-bounce@lists.fishpool.fi
Errors-to: mint-bounce@lists.fishpool.fi
X-original-sender: paul.wratt@gmail.com
Precedence: bulk
List-help: <mailto:ecartis@lists.fishpool.fi?Subject=help>
List-unsubscribe: <mailto:mint-request@lists.fishpool.fi?Subject=unsubscribe>
List-Id: <mint.lists.fishpool.fi>
X-List-ID: <mint.lists.fishpool.fi>
List-subscribe: <mailto:mint-request@lists.fishpool.fi?Subject=subscribe>
List-owner: <mailto:tjhukkan@fishpool.fi>
List-post: <mailto:mint@lists.fishpool.fi>

> (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).
you could always use a blit "stamp" or "signature" allowing
transmition of the signature instead of the data, which is already at
the destination. Better still you could collect a diff of the blit,
and send that instead (or combine it with a signature also)

> A few simple changes, which could relatively easily be
> incorporated into programs that have the source code available, would
> fix that, however.
This would be better (ease of implementation), however does it exclude
any of the above, or make that redundant. Speed of transmission, or
the size of the data transmitted, could allow the VDI to always be
ready for the next capture, not trying to play "catch up" with screen
updates.

Is it also possible to use (in/for VDI) custom vbl routines as well or
instead, it may have benefits for signature per (alternate) line, to
allow faster descision making, and any fullscreen blits could (by
default?) be transmitted as alternate screen lines (interlace, yes?)

a seperate "transission server" would allow VDI to maintain speed and
regular use, this server could just pump data as a stream, and that
could be either lossy or lossless, especially if UDP were used with
Lossy delivery, the potential to deliver hi rez's and hi bit depths
could be achieved

Paul