Message-Id: <9010252350.AA01682@jenzy.labs.tek.com>
To: dcc@ATHENA.MIT.EDU
Cc: vex@EXPO.LCS.MIT.EDU
Subject: Re: Round 3: device control and connectivity and VEX 
In-Reply-To: Your message of Fri, 19 Oct 90 16:06:45 -0400.
             <9010192006.AA28650@BOOM> 
Reply-To: toddb%sail.labs.tek.com@RELAY.CS.NET
From: toddb%sail.labs.tek.com@RELAY.CS.NET
Date: Thu, 25 Oct 90 16:50:07 -0700
Sender: toddb%jenzy.labs.tek.com@RELAY.CS.NET

> >To perform the equivalent task in an X station, you really don't one
> >one process handling the device (decompression from the disk) and another
> >handling the placement of the video on the screen.  They are the same
> >task!

>   This is a good example.  I would not bury this asynchronous realtime
>   activity inside the single X server process.  My approach is to
>   invoke an X request to render video into a window, then send a
>   request to the video device server to manage the disk.  Rendering
>   should start when data arrives (i.e., frame accurate synchronization).

Think about it now.  In some systems, the server is the one who must
copy the bits to the screen.  For example, a decompression system
may decompress to a private framebuffer or pixmap and the server copies
the result to the screen.  In this case it is both desirable and
necessary to have the server handle everything because a context
switch may be too expensive.

Surely you realize that your proposal makes it very difficult to 
do everything in the server (if I decide I want to do it that way),
while the VEX design allows you to do it either way without punishment.
That is, with VEX you can have it your way, and I can have it my way;
with your proposal, you can have it your way and I can have it *your* way.
I don't like that.

> >The only solution is to have the digitizer integrated with the frame
> >buffer
>   VEX
>   provides no way of saying RenderVideo when timecode (frame number)
>   is encountered.  Adding this to VEX should be considered.

Already considered.  VEX_SYNCHRONIZE is discussed in another letter.

---------------
internet: toddb@sail.labs.tek.com                                   c--Q Q
US:       Todd Brunhoff; Systems Architecture and Imaging Lab;          `
          Tektronix, Inc.;  Box 500  MS 50-321, Beaverton OR 97077      -
Phone:    (503) 627-1121