Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!mattd
From: mattd@Apple.COM (Matt Deatherage)
Newsgroups: comp.sys.apple2
Subject: Re: Video Card (Wait a minute!)
Message-ID: <54488@apple.Apple.COM>
Date: 30 Jun 91 17:35:50 GMT
References: <9106291504.AA14620@mcs.drexel.edu>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 59

In article <9106291504.AA14620@mcs.drexel.edu> ujmurphy@KING.MCS.DREXEL.EDU (Jim Murphy) writes:
>Tim Meekins said this, but I'm not in the mood to quote everyone else:
>
>( In respect to the feasibility of adding a QuickDraw II compatible video card
>( to the IIGS...)
>
>> Ah, but Apple has published the low-level entry points for QuickDraw II,
>> so it is quite feasable. After all, these all need to be patched to write
>> printer drivers. Since thrid parties have written printer drivers, I don't
>> see why patches in an init couldn't be written for a video. The only
>> problem lies in QuickDraw II's assumption of how palettes are stored and
>> formed. Worse, the number of applications that assume these things.
>
However, although we've published the _main_ QuickDraw bottlenecks that
most applications would need to do alternate drawing methods, we haven't
published nearly all of them, and certainly not enough to let you invent a
new physical drawing paradigm.

>     We do have one other major problem. Certain parts of the toolbox do not
>use QuickDraw II when drawing to the screen. A perfect example is the Menu 
>Manager in respect to menu caching. It blasts the images right to the screen
>RAM. This is a major problem, unless it is either changed in the future by
>Apple to be more friendly, or it can be successfully patched. There are most
>assuredly other issues, but this is one that is foremost in my mind.
>
Jim, you're suffering from a delusion that plagues magazine writers from
time to time.  The rules are created to assist in compatibility with the
system software.  The System Software can maintain compatibility with itself
in whatever way it chooses, including in ways that are not accessible to
non-system software programs.

The Menu Manager can draw directly to the screen if it wants because it's
part of the system software, and it knows as well as QuickDraw does that
there's currently only one screen, and that QuickDraw really isn't non-Apple
extensible to fix that.  If this were to change in QuickDraw, it would
probably also change in the Menu Manager.

As if that wasn't enough (and it is), you also seem to be forgetting that
the Menu Manager would be following external rules totally if it used the
information in the locInfo record of the Menu Manager port to determine
what pixels in the pixel map a given rectangle will occupy and calculates
memory addresses from there.  (In fact, it may actually be doing that.)  The
Menu Manager _has_ to read screen memory directly to cache the image under
a menu or it would have to call _RefreshDesktop every time a pull-down menu
was released.

Fortunately, the Menu Manager _is_ system software and it can do that, and as
explained above even non-system software could do this.

Sorry to burst your "Apple's breaking it's own rules again bubble," though.  :)

>Jim Murphy                             "I know that you believe you understand
-- 
============================================================================
Matt Deatherage, Developer Technical  | The opinions expressed herein are
Support, Apple Computer, Inc.         | not those of Apple Computer, and
Personal mail only, please.  Thanks.  | shame on you for thinking otherwise.
^^^^^^^^ Technical questions are not personal. Please post them instead.
============================================================================