Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!UCSD.EDU!sdempsey
From: sdempsey@UCSD.EDU (Steve Dempsey)
Newsgroups: comp.sys.sgi
Subject: What is your StereoView aspect ratio?
Message-ID: <9009010113.AA17280@chem.chem.ucsd.edu>
Date: 1 Sep 90 01:13:24 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 66

I'm having a devil of a time determining what the correct aspect ratio
of a fullscreen stereo raster (1280x492 pixels) is.  This applies only to
the new StereoView option that supports programmable switching of the
monitor type with setmonitor(STR_RECT).  So far I have three possibilities
(well, two possibilities and one reality):

1.  The StereoView User's Guide (version 1.0) indicates that the correct
    aspect ratio is 1.30, based on 492 stereo scanlines expanding to the
    same physical size as 984 regular scanlines.  

	1280 / 984 = 1.30

2.  Thant Tessman of SGI has reported to me that the Mitsubishi HL6915STK
    multisync monitor is 'smart' in that it expands the vertical raster
    size to fit a programmed physical size, regardless of the actual number
    of scanlines.  So the stereo aspect ratio should be the same as a
    normal 1280x1024 raster.

	1280 / 1024 = 1.25

3.  On our 340VGX with the monitor named above I measured a 1280x1024
    raster to make sure the monitor was setup properly, and indeed I
    measured an aspect ratio of 1.25.  I then switched the monitor with
    setmonitor(STR_RECT).  The raster width did not change, but the raster
    height definitely shrank.  I measured the aspect ratio at 1.38!
    I called the Hotline and was told that this is "normal".

IS IT NORMAL FOR YOU?
    I would appreciate it if those of you who have StereoView and the "smart"
    monitor would run the little test program below and measure your
    aspect ratios and send me the results.  I can't make any sense out of
    the 1.38 figure and I fear that it may vary among machines.  If we all
    come up with the same number then I'll just accept it as some sort of
    video voodoo and put the 1.38 figure into my code.  Otherwise I'll at
    least have some ammunition to persuade SGI that a real problem exists here.

#include <gl.h>
#include <get.h>
#include <device.h>

main()
    {
    short     val;

    foreground();
    noborder();
    prefposition(0, 1279, 0, 1023);
    winopen("");
    qdevice(KEYBD);
    color(RED);
    clear();
    while( qread(&val) != KEYBD ); /* pause here to measure the normal screen */
    color(GREEN);
    clear();
    sleep(1);	/* don't crash the VGX graphics pipe! */
    setmonitor(STR_RECT);
    while( qread(&val) != KEYBD ); /* pause here to measure the stereo screen */
    setmonitor(HZ60);
    }

---------------------------------------------------------------------------
Steve Dempsey					voice:	  (619) 534-0208
Dept. of Chemistry Computer Facility, 0314	UUCP:	  ucsd!sdempsey
University of Calif. at San Diego		BITNET:	  sdempsey@ucsd
9500 Gilman Drive				INTERNET: sdempsey@ucsd.edu
La Jolla, CA 92093-0314				fax:	  (619) 534-0058