From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] lucio- now: student projects
From: forsyth@caldo.demon.co.uk
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20020312102009.D97E1199EE@mail.cse.psu.edu>
Date: Tue, 12 Mar 2002 10:13:22 +0000
Topicbox-Message-UUID: 651d1af4-eaca-11e9-9e20-41e7f4b1d025

>>	I believe that most real-time video boards write directly into
>>	the video adaptor's memory - how would this best be integrated with
>>	the Plan 9 graphics system?

it's not uncommon now to find that the `video adapter's memory'
is the processor's memory; there's even a separate MMU for it.

>>	be a bottleneck? X has come up with techniques to let the application
>>	write directly into a window's memory to get reasonable performance in this
>>	situation - how would Plan 9 address this, hopefully without these
>>	extra levels of complication?

i think a write to /dev/draw of properly aligned and formatted data to
an unobscured window amounts to a memmove
from user memory directly into a linearly-mapped frame buffer.

unlike 8-1/2 where /dev/bitblt was multiplexed by 8-1/2 itself as a file server
(i'm not using the Unicode 1/2 because of some stupid mail gateways), with rio
applications us their own connection to /dev/draw directly, and application graphics operations
therefore go direct to the frame buffer (if there is one) through the
kernel without going through rio.

scheduling the frame rate precisely might or might not be a problem.
i'd know already except that the nicest free DVD playing software i can
find looks all right itself but is buried in one of those ./configure marvels.