Message-Id: <8908161801.AA16386@tekcrl.LABS.TEK.COM>
To: keith@expo.lcs.mit.edu
Cc: xvideo@expo.lcs.mit.edu
Subject: Re: Comments on VEX version 3.4 (89/08/02)
In-Reply-To: Your message of Wed, 09 Aug 89 14:38:30 -0400.
	     <8908091838.AA12645@xenon.lcs.mit.edu>
Date: 16 Aug 89 11:01:41 PDT (Wed)
From: Todd Brunhoff <toddb%tekcrl.labs.tek.com@relay.cs.net>

> > 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?

This all depends on whether Composite is asserted for the video output.
I'm not sure what you mean by "affect" because a VOR is implied
by a capture operation, and like GetImage, doesn't "affect" anything.
Only write operations "affect" things.

> > [control atoms interned by the extension when the server starts]
>
> "server starts" is a vague term.  Typically, server reset is used instead;

This is not a recurring event.  They are predefined by the server extension
just like the core protocol predefines its set of atoms (pp. 353, sec. 7 of
protocol in digital press book).  If you feel strongly about this, I'd
be willing to change it to "predefined atoms".

> >    FRACTION:           [ numerator, denominator: INT32 ]
>
> Should denominator be restricted to positive (> 0) values? (else Value
> error).

Yes.  Words added.

> 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...

I disagree.  This would be a reoganization for no added benefit, and
in fact increases the size and complexity of QueryVideo somewhat
due to reintroducing the data elsewhere.
The allowed-depths is just that.  They are those that are unique
to the video hardware, whatever their use.  If you need to have
the depth information separated at the Xlib level, that can be
easily done.

> Why is the screen returned in the response?

[ First, change the window element in VideoConnectivityState and
  VideoChange events to be a CARD8 screen, an oversite on my part. ]
It is a matter of correlating data that is not associated with a
particular window, but with a screen.  The screen identifies the set of
QueryVideo information
associated with each screen (obviously).  When you receive a VideoChange
event, you must decide which of your QueryVideo information sets are out
of date, and reissue a new QueryVideo.  This can be done by simply using
the screen as an index.  The alternative, is to have
the VideoChange and VideoConnectivity events return a root window,
and then iterate through each set of QueryVideo information
looking for a matching root window.  The screen index is simpler
because widgets don't necessarily know the screen they are associated
with (I think).

> 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...

In this case, Composite will be asserted, and the statements you quote
no longer hold.  Composite is a hint as to the hardware capability.
It can be ignored by simpler software, but I believe is useful
for programs like xwd that want to produce a hardcopy of the screen.

> Why is the border included in the CaptureVideo output?

It can be.  Just like the border can be included in a GetImage request.
Same idea.

> 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 current document joins the two clauses with an "and".  Join them
with a "thus" and tell me if it reads better.  The clauses are saying
the same thing.

> >     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'

Yes.  Good eye.  Thanks.

> "Siblings or children" is not sufficient [for clip-size]; I assume any
> occluding window should be included in this set.

Correct.  I have changed it to say simply "other windows".

> >                                             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.

It is useful for stupid hardware that has funny clipping restraints,
like if it a scan line in the video picture is interrupted, it
cannot be started up again.  The client may want to respond by stopping
the video.  Until the situation goes away (VisibilityNotify).

> Will the number of adjacency matrices grow exponentially (in general) with
> the number of devices added to the system?

Yes.

> 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?

If every device could be both a source and a destination to every other
device simultaneously, then yes, it would group exponentially.  Let's
say you have a matrix with n rows and columns (implying you have n-1 devices
and 1 video input and 1 video output).  Then the potential is 2**(n**2)
matrices.  Three devices (n-1) would potentially cause 64k matricies,
each 16 bytes in size, or a total of 1 megabyte to be sent down the wire.

In reality, few if any devices will ever connect to themselves as both
a source and a destination, implying that the diagonal will always be 
false.  Most devices are either a source or a sink, not both, which
means that every true above the diagonal implies that the mirror entry
below the diagonal is always false.  Most devices will connect to one and
only one other device, which implies that there will never be more than
one true in any row or column.  The permutations for an n-set are n!, and
the above limitations works out to be more than n-squared, but less than n!.
For example, consider two devices, one video input and one video output,
giving a 3x3 matrix.  The permutations would be

    000 001 010 000 010      000 000 000 000 000      000 001 000 000 000
    000 000 000 001 001  or  000 000 000 100 100  or  000 000 000 001 001
    000 000 000 000 000      000 100 010 000 010      000 000 010 000 010

etc., or more simply, with just the cells above the diagonal:

    00 01 10 00 10
     0  0  0  1  1

A 4X4 matrix requires at most 15 permutations; 5X5 requires 52; 6X6
requires 203.  If you have 7 devices, one input and one output, the matrix
will be an 8X8, and requires at most 4140 matrices with 64 bytes each,
totaling 264960 bytes.  Do me a favor, and ask Bob if its ok to have an
array of bits instead of CARD8s for this.  I will be attending a class on
video post-production soon and will ask how many devices a studio
might actually have.

> This is rather confusing...

You are right, that was awful English.  I will substitute the following
words:
    Clients that do not need access to digitized pixels should use
    an InputOutput window as a destination instead of a VideoBuffer,
    because this is the most portable among VEX implementations,
    and it allows the server to display the video picture using
    the most effictient means.


> 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

This is not really what I intended to say, although this may be the ultimate
result.  I mean to define what happens on a StopVideo request, depending
on whether the hardware is Composite and if a VideoBuffer was used
or not.  Substitute these words:

    ... then the visual effect
    is that all traces of the video picture will disappear, nothing is
    retained /+ ; the operational effect is the same as changing the
    translucent for the window to 100% graphic (see CreateWindow description
    in this document).  +/ If a RenderVideo...

> 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.

A separate paper, "VEX Your Hardware", deals with things such as this
and I'll work some words in there.  Blech.  You may notice that there
are plenty of things in the VEX extension that are scarce resources,
and I am trying to design a reasonable way of redirecting some or
all VEX requests, but I suspect that that will be delayed some.

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

I intended to take advantage of the same description used by the
core protocol, and will include it explicitly at the beginning of
the event section:

    Every VEX event also contains the least-significant 16 bits of the
    sequence number of the last request issued by the client that was (or
    is currently being) processed by the server.