From: dcc@ATHENA.MIT.EDU
Message-Id: <8908251536.AA00588@THANATOS.MIT.EDU>
To: xvideo@expo.lcs.mit.edu
Subject: Introduction and basic questions.
Date: Fri, 25 Aug 89 11:36:23 EDT


  - - - - - - - - 
  To xvideo folks:

  I'm new to the xvideo distribution and to the VEX protocol, and
  though I've had some dialog with Todd, I'm still a bit naive to some
  specifics of VEX.  In my reading of the xvideo archive I've seen
  lots of rationale discussed for various things, but I still have
  some basic questions and concerns.

  - - - - - - - - 


  Let me introduce some problem or problems I'm seeing.  The VEX
  protocol touches on several interesting and hard problems, many of
  which are not strictly (or even predominantly) related to video:
  compositing, multiple heterogeneous frame buffers, transparency,
  translucency, overlays, multibuffering, and the interaction of
  multiple graphical methods within an object.  I believe that VEX
  should attempt to avoid these issues for following reasons: (1)
  there doesn't seem to be a standard approach taken by hardware in
  supporting these capabilities, (2) the issues interact with other
  extensions as well as the core, and (3) each capability is
  practically large enough to warrant an extension of its own.

  Now, I realize that for video hardware to be interesting and
  reasonably supported in an X protocol, it is inevitable that some of
  these problems must be addressed.  All I'm saying is that I believe
  every effort should be made to skirt these issues so they can be
  addressed, without complication, on their own, and to define a video
  extension that standardize abstractions that are common (or
  standard) among applications that use video and displays that
  support video.

  My perspective is that video is a method of display, an equal
  citizen with bitmap graphics (X core), 3D graphics, Imaging, etc...
  though, as Todd pointed out, it has some stringent constraints and
  requirements.

  I'll try to get specific.  The concept of translucency as proposed
  by VEX is really a specific implementation of two way compositing
  (compositing being the composition of a display by combining multiple
  images together using any number of a variety functions).
  Compositing is a much broader problem that includes mixing multiple
  images together (not necessarily two) with various combining
  functions (not just percentage by table lookup), either statically
  or dynamically, on demand or automatically, etc...

  So, for the time being, I'd try to skirt the compositing issue in
  the VEX protocol by exposing device specific functionality through
  the use of existing mechanisms and private extensions, and wait for
  a broader compositing extension to be defined.

  I'll try to get even more specific:

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

  Problem:

  VEX has attached an attribute to the Window object with a semantic
  that is related to compositing, but with a function that is not
  generally applicable to compositing.

  Solution:

  Remove the attributes of Translucent and Blendmap from the Window.

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

  Problem:

  How is a device with such a frame buffer supported and utilized
  though X and VEX?

  Solution:

  The manufacturer of the device provides a server that makes their
  special frame buffer accessible and useful.  Now for the sake of
  argument, I will attempt to quickly define the content of such an
  extension:

    The goal is to permit an application to create an image that is
    produced by compositing two other images (one graphics and one video)
    via a third image (blend).

    One simple (no new semantics) way to achieve this is for the
    server to define a new VisualType: Blend.

    An application would create a Blend window (a window of VisualType
    Blend) as the child of a normal graphics window and display a
    video image into a rectangle of the Blend window.  Graphics is
    drawn to the parent window using the subwindow-mode =
    IncludeInferiors GC attribute.  Thus the graphics image is drawn
    over the video image and the blend image is drawn independently.

    Since the blending function is a table lookup, I would overload
    the use of Colormaps to manage blend lookup tables.  If the
    blending function was something different, the extension would
    probably need additional semantics.

  I'm interested in how this approach is deficient in addressing the
  needs of an application and the capability of the hardware, but
  that's not the point.  The point is that I can easily think of a
  half dozen variations on the theme, and private extensions should
  be defined to expose the specific capabilities of different devices.

  --david carver