Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!spool.mu.edu!think.com!mintaka!olivea!apple!dlyons
From: dlyons@Apple.COM (David A. Lyons)
Newsgroups: comp.sys.apple2
Subject: Re: Synnovision
Message-ID: <51701@apple.Apple.COM>
Date: 19 Apr 91 08:08:29 GMT
References: <1991Apr19.022213.22524@mcs.drexel.edu> <1991Apr19.051118.5726@nntp-server.caltech.edu>
Distribution: all
Organization: Apple Computer Inc., Cupertino, CA
Lines: 58

In article <1991Apr19.051118.5726@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes:
>ujmurphy@mcs.drexel.edu (Jim Murphy) writes:
>>[recommends Apple provide QuickDraw II support for the video overlay card
>> and perhaps 3rd-party cards]
>
>Apple keeps shuffling their feet when we talk about this. I think they are
>either afraid to deal with all the hardcoded crud in the toolbox (especially
>the interface -- Dave Lyons can probably give few examples that would break
>if 256 colors were present on screen, but won't share any ideas as to new
>toolbox calls to do the job, like MenuNewRes2 or something along those lines),
>or they are trying to keep us from developing it on our own and getting burnt.
>
>Todd Whitesel
>toddpw @ tybalt.caltech.edu

Rather than take offense at the above, I will explain my point of view.

(1) If QuickDraw were modified to support a nonlinear screen buffer, or
    to support pixel depths other than 2 or 4, a large fraction of
    existing software would be incompatible with the new modes.

    Adding new toolbox calls does not make incompatible software any more
    compatible.  With the current set of calls, it is already possible for
    an application to make a few checks about the drawing environment and
    special-case drawing directly to the screen if necessary for speed,
    but to use QuickDraw to be -safe- if it detects at runtime that there
    is something different about the environment.

(2) The video overlay card is not dirt-cheap, and there aren't billions
    and billions of them out there.

(3) If we patch out the Menu Manager to make it not hard-code any screen
    addresses, all the ROM 3 folks who *don't* use a special video card
    would be paying an pointless penalty in RAM space and execution speed.

(4) Having more than one screen size and more than one aspect ratio would
    wreak havoc with several areas.  Everything would look squashed in most
    applications.  Applications that, say, save the locations of your windows
    and re-open them in the same place could easily open a window partly or
    totally offscreen, or draw icons offscreen, if the saved information
    comes from a different configuration.  The system could partially but
    not completely compensate for that.

(5) There is no shortage of toolbox enhancements that will benefit a wide
    audience of developers and customers.

For these reasons, investigation of video card support is not high on my
priority list.  It's on there, but not high.


-- 
David A. Lyons, Apple Computer, Inc.      |   DAL Systems
Apple II System Software Engineer         |   P.O. Box 875
America Online: Dave Lyons                |   Cupertino, CA 95015-0875
GEnie: D.LYONS2 or DAVE.LYONS         CompuServe: 72177,3233
Internet/BITNET:  dlyons@apple.com    UUCP:  ...!ames!apple!dlyons
   
My opinions are my own, not Apple's.