From: keith@expo.lcs.mit.edu
Message-Id: <8908091838.AA12645@xenon.lcs.mit.edu>
To: xvideo@expo.lcs.mit.edu
Subject: Comments on VEX version 3.4 (89/08/02)
Date: Wed, 09 Aug 89 14:38:30 -0400


Some comments on VEX from a reading of protocol version 3.4 (89/08/02)

First off, I should like to thank Todd for his perseverance in creating
this proposal; it looks like a workable compromise in the face of
wildly different hardware implementations.  My comments are mostly
minor, and, except for the role of visuals associated with translucent
pixmaps, do not affect the design in any real way.

(Original text from the document is offset by angle brackets)

> Video output region (VOR)
>     This is defined as the set of pixels on the screen or in a pixmap
>     that are being encoded by a CaptureGraphics request, whether it
>     is accomplished by reading pixels from a framebuffer or by analog
>     conversion.

I assume "or by analog conversion" would only affect areas of a VIR
being captured?  Or is this statement saying something else?

>     CONTROL:            [ name: ATOM
>                           id: VIDEOID
>                           event: BOOL
>                           format: { 8, 16, 32 }
>                           length: CARD32 ]
> 
>     The control structure is used to represent the capabilities of the
>     "knobs" and "dials" on various video hardware.  It is returned by
>     the QueryVideo request.  The name in a control is a control atom
>     interned by the extension when the server starts.
> 

"server starts" is a vague term.  Typically, server reset is used instead;
this provides a well-understood timeframe which provides essentially the
same notion (i.e. while no client connections are active).  This also allows
the system to be dynamically reconfigured without "restarting" (whatever
that means) the server.  I would be more in favor of stating that the atoms
are interned by the server before being advertised in a QueryVideo response.

>    FRACTION:           [ numerator, denominator: INT32 ]

Should denominator be restricted to positive (> 0) values? (else Value
error).

>     RENDERMODEL:        [ depth: CARD8
>                           visual-id: VISUALID ]
> 
>     This type is used by QueryVideo to reference the depth and visual
>     types used by the VEX extension to describe VideoBuffer windows,
>     their parents, and translucent pixmaps and blendmaps.  The visuals
>     are described by the connection setup and/or the QueryVideo
>     request.

I'm not sure a RENDERMODEL is the appropriate description for the
translucent pixmaps and blendmaps.  I think allowed-depths should be
restricted to video-input/video-output, while a separate list should be used
for blending; replace blendmap-models with

	blend-depths: LISTofDEPTH

This does eliminate the current blendmap-per-depth information which
exists in the document; perhaps that information should be added back
by modifying LISTofDEPTH to include the blendmap.  The core protocol
does not have this information about colormaps; I'm not sure why.  I think
the separation of visuals used for blending and visuals used for graphics
is useful and necessary.

This seems reasonable to me, in that the "visual" associated with blending
is not the same as a StaticGray visual used for windows.  Is this too
complicated?  

>     This request returns information about video hardware for the screen
>     associated with the specified window.  The screen is returned as          |
>     the first element in the reply.                                           |

Why is the screen returned in the response?  I'm not sure this is useful;
although it probably adds nothing to the packet size, the client can
easily (and probably already has) found the screen number.

>     windows for a video input must be created using a depth/visual whose      |
>     whose intersection has a Buffer bit set.  If a video input has no Buffer  |

I assume the double 'whose' has already been removed.

>     If Composite is not asserted, but Window and Buffer are specified
>     somewhere in the row, then graphic and video pixels occupy separate
>     frame buffers.  In this case, pixels copied from an AVBW, are
>     guaranteed to be graphic pixels, even in the AVR, unless occluded         |
>     by other windows of the same depth and visual.  Pixels copied from
>     a VideoBuffer window are guaranteed to be pixels from that window         |
>     unless occluded by other windows of the same depth and visual.


The restriction that pixels not occluded by other windows of the same
depth and visual be copied correctly is not supportable by some hardware.
For example, my 8-bit CFB server advertises 6 visuals; every one of which
uses the same physical pixels on the screen.  Making my server save
away pixels occluded by windows with different visualID's is not
feasible.  The GetImage request leaves such areas undefined (as well
as most of the rest of the image).  GetImage is not expected to be as
generally used as CaptureVideo, but I think the guarantees which this
request provides about contents should be reconsidered.

>     If Window is asserted, then a video output can capture the
>     intersecting depth visual in an InputOutput window, including the
>     border.  If Buffer is asserted, then a VideoBuffer window with the
>     intersecting depth visual can be captured, including the border.
>     If Composite is asserted, then Window and Buffer must be asserted,
>     and AVBWs will be captured after their primaries are mixed
>     according to each associated translucent pixmap and blendmap.  (If        |
>     Composite is asserted, it will be asserted for all the entire row)        |
>     If Composite is not asserted, but Window and Buffer are specified,        |
>     then capture from an InputOutput window will never include pixels         |
>     from a VideoBuffer window, and regions of the source that are             |
>     occluded by a VideoBuffer window are undefined: it is hardware            |
>     dependent.  Likewise, capture from a VideoBuffer window will never        |
>     include pixels from non-VideoBuffer windows, and regions of the source    |
>     that are occluded by an InputOutput window are undefined; it is hardware  |
>     dependent.  If Pixmap is asserted, then a pixmap with the                 |
>     intersecting depth can be captured.

A couple of questions about this section.

Why is the border included in the CaptureVideo output?  The RenderVideo does
not render to the border; I think symmetry with that request is more
useful than symmetry with GetImage.

The statements:

	capture from an InputOutput window will never include pixels
 		from a VideoBuffer window

 	regions of the source that are occluded by a VideoBuffer
 		window are undefined

seem to contradict each other.  Am I missing something?

>     The device-atoms correspond to the video outputs and are
>     server-dependent strings interned at startup.  They are intended to

I assume this is meant to be 'video devices', not 'video outputs'

>     The clip-size list corresponds to the list of video inputs, and
>     describes the smallest rectangle that can be used to clip a
>     VideoBuffer window partly occluded by siblings or children.

"Siblings or children" is not sufficient here; I assume any occluding window
should be included in this set.

>                                             In addition, other
>     constraints that VEX cannot express may be violated, and a
>     VideoViolation event may be generated.

I'm not sure this is useful.  If VEX is not able to describe the
limitations required by the hardware, how is the client expected to
respond to this event?  I guess undoing the violating request is
probably sufficient.


Some comments on the adajacency matrices:

First off:  I suspect I don't understand this section correctly yet;
it is rather convoluted.  I'm sure I don't grasp the requirements for
making this so complicated.

Will the number of adjacency matrices grow exponentially (in general) with
the number of devices added to the system?  Could this cause QueryVideo
to send megabytes of adjacency matrices over the wire to every client?

>     When a VideoBuffer window is used as a destination, clients               +
>     that do not need access to digitized pixels should use an InputOutput     +
>     window as a destination, because this is the most portable.               +

This is rather confusing; I suspect the indended meaning is more like:

    Clients that do not need access to digitized pixels should use
    an InputOutput window as the destination instead of a VideoBuffer
    as this is a more portable scheme.

>     If a RenderVideo on InputOutput window W is followed by a StopVideo       +
>     on W, and Composite is asserted in the video-input-models for the         +
>     video input source, then the visible result on the screen is              +
>     undefined, because it is hardware dependent.  Under the same              +
>     circumstances, if Composite is not asserted, then the visual effect       +
>     is that all traces of the video picture will disappear, nothing is        +
>     retained.  If a RenderVideo on a VideoBuffer window W is followed         +
>     by a StopVideo on W, the result in W is the pixels take on the            +
>     value of the last frame acquired: they can be manipulated by other        +
>     X requests.                                                               +

What does "all traces of the video picture will disappear" mean?  A clearer
statement would be:

	the VIR is filled with the background of the window

Should an expose event be generated?

> InstallBlendmap
>     bmap: COLORMAP

I suspect some words about ICCCM extensions to support VEX would be
useful here; blendmaps are a scarce resource which should probably be
managed by a separate program.  (I know, this doesn't really belong
in this document, but many people have been confused by the lack of
wording in the protocol document about "expected" usage for some
of the requests)

> VideoControl
>     vid: VIDEOID
>     name: ATOM
>     state: { Success, Fail }
>     time: TIMESTAMP

I think this event should indicate which request it was associated with;
perhaps the serial number of that request should be included.