Re: SecondSight and shadowing

["geoff" <geoff@a2central.com.remove-so7-this>]

  To: Toinet
 > As usual, Inside Mac of Color Quickdraw is worth reading especially
 > the Graphics Driver part which separates the display process into
 > separate layers: one for the graphic port, one for the display port.
 > Once again, a neat documentation from Apple.

I didn't know this existed, thanks for pointing it out.

 > Quickdraw II (and its standard routines) is the core toolset but a complete 
 > desktop application requires the following toolsets to be updated: Window 
 > Manager, Menu Manager, Control Manager, some other toolsets and the one I 
 > especially like: the Midi toolset as it
 > modifies the QD II Cursor routines to perform MidiInputPoll calls.
 >
 > If you want to keep compatibility with the original modes (320*200*16
 > and 640*200*4), you must add other modes =3D> update the toolsets 
 > accordingly =3D> modify the ToolTable resource file to handle the new types 
 > =3D> update the ToolLocator toolset. And please, do not forget the display 
 > driver which outputs data to the video board ;-)

 > That is why I hoped the SS would be smart enough to read data from
 > other places than the display RAM of the IIgs. Too bad!

 > Ahem! What I see from the toolsets is that the _GetMasterSCB IS the
 > main call! Now, I understand why Facelift disappeared!

 > antoine

What do you think about this?

Background: Look into CloseView.  It copies data from an off screen grafport 
to the SHR screen (the off screen port happens to be the non-displayed 
non-shadowed SHR screen, but we can pretend it isn't SHR memory space). 
Closeview patches tools and vectors, including the cursor routines.


Using this concept for the SecondSight, a grafport with the 640 mode in the 
port's SCB and a size of 640x480 needs to be created anywhere in GS memory. 
Instead of drawing to the screen grafport, have all drawing occur in this 
grafport.  Palette information will still be in the standard $E1 SHR location.
 A heartbeat task then copies from the GS memory to the Second Sight (assume 
one can add some optimizations by having a hook into stdprocs so one know 
which lines really need to be updated).  This is a bottleneck even on an 
accelerated GS, but it does provide a higher resolution for desktop apps.  
This method then allows for future revisions where stdprocs can then be used 
to write to the SecondSight directly, avoiding the heartbeat copy and 
improving performance. And by not drawing the cursor and relying on the 
SecondSight hardware cursor (losing multiple color and animated cursors 
support), this will improve performance,

This appears to keep compatibility with the native GS SCB to a certain 
degree--apps or routines which assume the screen size is 200 lines will not 
work correctly and apps which customize the SCBs on individual lines will run 
into limitations.  But this should work for most existing apps.

These tools need to be patched:

System Menu bar
Get SCB / Set SCB --support lines above 200 in a private table
and the other tools which CloseView patches.

Is there an understanding that I do not have where significantly more tools 
need patching to use this method to let the IIgs have a higher resolution with 
the SecondSight?

This appears to be minimal work to get an immediate benefit (with the caveat 
that full screen scrolling will be slow).

Geoff