

Problems With Video Windows		- Russ Sasnett  6/2/87
===========================


	"We thank you for your support."
		- Bartles & James


	Over the last couple of weeks, I have been putting video windows
through their paces, trying to determine if the current version of the
Parallax driver/server is capable of meeting the needs of the VCL for
the scheduled fall release. I have uncovered a number of quirks, potential
bugs, and some work-arounds, as noted below. The next step is to decide
whether these problems are worth fixing under V10, or if we can live with 
the current level of functionality.

Semi-Fatal Errors

	There are still a number of situations which will either kill or 
severely maim the server. Among these:

	1) 	If you are displaying a live video window, and the video
		signal is interrupted, server response slows to a crawl,
		Xplx errors start popping up, the X input buffers overflow,
		and the system Errlog fills up. The same thing happens if
		you bring up a video window with no input signal connected.
		The only ways to get out of this are a) feed it some video
		so the server gives you normal response or b) suffer through
		trying to move the mouse to a command window at 1/100 of
		normal speed, and killing the process. 

	2)	If you try to scale a video window, or display a still video
		window while video is interrupted or not present, you get 
		"Xplx: Error 0xa, State 0x4" and a high probability of a 
		server crash.

	3)	If you make a lot of calls to XScaleVideo in succession, even
		with XSync() calls scattered in between, sooner or later you
		get an "80 Read Bus Error" or some such thing, and the machine
		quickly panics and shuts itself down.

Other Problems and Errors

	The following problems are not fatal, but they do represent either a
failure to perform according to the X spec, or a difficulty that will make
application development more exciting than it needs to be.

	1)	If you move a video window, you will get garbage. Some of
		the luminance will still seem to be correct, but in general
		the color portion of your image is history. Naturally,
		X decides not to inform you that the window has moved, so
		if you want to refresh it you must either continuously poll 
		the window with XQueryWindow(), or set a timer and 
		automatically update the image. My attempts to poll the
		window in order to discover moves have so far met with 
		disaster. 

		My suspicion is that the server is unable to tell the
		difference between a video window and any other window.
		If the server could know that a window is of type VIDEO,
		it could use the DAMVV (Display Attribute Map: Video mode)
		instruction before moving or copy the windows. Currently,
		I'll bet it uses DAMVG mode, so that only video that gets
		digitized with a FLASH instruction works properly.

		Also in this vein, the window manager(s) should know about
		the restrictions on video window placement - that is, the
		x-coord must be a multiple of 16, as must the width. The
		XSetResizeHint() call will take care of the width requirement,
		but the base x-coord is free to end up anywhere. Similarly,
		programs will want to enforce some constraints on window
		management so that some "expensive" video windows don't
		get obscured. If I just spent 15 seconds building a composite
		map, I don't want a stupid xterm to blow it away inside
		my application. I guess what I'm saying is we'll probably
		want to kill the standard window manager and handle resize
		and move events ourselves.
		
	2)	I have been unable to duplicate this, but once by accident
		a live video window that got unmapped left a 1-bit deep
		partial black & white video image on the screen. Never 
		happened again.

	3)	None of the routines in the Xvid.c file guarantee that
		their parameters meet the Parallax requirements for video
		image data (x and width on most of them must be modulo 16).
		If you aren't very careful, you can easily bash the server
		and have no clue what went wrong. This is easily fixed.

		Also, an obscure note is that the color index sent to
		XSetVideoColor() must be ODD, and the planemask for 
		video overlay graphics set to 0x3f or less, for overlay
		graphics to work. This is not a bug, but a requirement
		not enforced by XSetVideoColor(). Again, easily fixed.
		
	4)	Apparantly, XScaleVideo() works by FLASH-ing into offscreen
		memory first, and then BOXZV-ing into the display. However,
		under certain circumstances, it seems as though the offscreen
		area only gets updated on the first call to XScaleVideo().
		Several calls to XScaleVideo() on the same window 
		result in the same (initial) image being transferred
		to the screen. This is wrong. If you alternate between 2
		different windows, the problem is cured; but this is pretty
		messy and time-consuming. Another fix is to XUnmapWindow()
		and XMapWindow() just before each call; also unacceptable
		in most situations.

	5)	XPixmapGetZ() just does not work properly on video windows. 
		It is supposed to fetch the bits from a Pixmap and return 
		them to the host in a buffer. I get back some of the bits,
		but in a strange and unusable order. Come see me for a visual
		demonstration.

	6)	XPixmapBitsPutZ() doesn't work on video windows. It is 
		supposed to load a window with host-supplied bits, and it
		may be doing that, but it certainly doesn't work with the
		companion function above. Also, the server should use the
		DAMVV function to mark these as video pixels when it stuffs
		them in.

	7)	As a consequence of (5) and (6), users will be unable to
		save and re-load any portion of a video image from the host's
		memory or disk. This is	necessary for some of the Architecture
		projects, and also it would be nice to convert and load Targa 
		images of diagrams and whatnot for September. This also means
		users will be unable to print video windows (xwd and xwud 
		depend on those routines also). 

	8)	XPixmapSave() WILL allow you to store part or all of a
		video window in offscreen memory. BUT, XPixmapPut() doesn't
		set the DAM, and so you can't move them back successfully.
		However, the bits seem to be in all the right places.
		Likewise with XMoveArea() and XCopyArea(), I'm sure. This
		means you can't drag around or move or copy a video window.

	9)	It is currently impossible to have a full-screen moving
		video image under X. You might be able to sneak an 
		instruction to the server to start the Zoom(), and then
		either a) grab the server until the segment is finished 
		playing, or b) trap all X events that don't relate to 
		that video window, and warp the mouse to live only in that 
		area of the screen.

	10)	It is currently impossible to tell X where to store offscreen
		Pixmaps; it handles the storage for you. Occasionally the
		programmer may know more than X; a minor quibble.

	11)	If you drag an outline of a window or icon over a still 
		video image, you leave behind some garbage in your wake.

	12)	You can't invoke BOXZ or BOXZV on an arbitrary pixmap;
		this means you can only scale the current incoming video 
		image, and not anything already in the frame buffer.


That's about all I can think of for now. I'm sure other implications will
pop up that I haven't thought of. I'm not advocating implementing every
last thing we would ever want under an X10 that will live for only a few
more months. This is just to inform people a little more concretely as to
what is and isn't possible as of this moment (given my limited understanding).
Your thoughts and comments are needed as to what you ABSOLUTELY MUST HAVE to
develop your applications for September, while remembering that we'll all be 
switching to an X11 that is much more tolerant of these device-specific 
issues. Depending on the difficulty and time required, a limited subset of 
these problems could be solved for the September release. 
