Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think!snorkelwacker!ira.uka.de!smurf!urlichs
From: urlichs@smurf.ira.uka.de
Newsgroups: comp.sys.mac.programmer
Subject: Screens and windows (was Re: A neat INIT needed)
Message-ID: <1497@smurf.ira.uka.de>
Date: 7 Feb 90 21:18:12 GMT
References: <1651@majestix.liu.se> <104700075@p.cs.uiuc.edu>
Organization: University of Karlsruhe, FRG
Lines: 51

In comp.sys.mac.programmer gillies@p.cs.uiuc.edu writes:
< >Good idea -- sort of a "Stepping In".  
< 
< Actually, if I ever had some time, I was going to try and write one of
< these.  It would make a 5-star MacTutor article.
< 
Let's do it!

Quick and dirty approach:
- Make your own gDevice. Write a driver which manages a fake color table.
- Allocate the storage for your pseudo-screen somewhere convenient.
- Set its coordinates correctly, and update grayRegion and similar data
  structures. (You'll have to do that at INIT time or something.)
- Make a window to show your non-screen. Create a palette from the color table
  (see step one), and attach it to that window.
- At convenient times, copy your buffer to your window, using CopyBits or
  similar. (Convenient: not at VBL time because you have to draw things!
  Probably patch _Button or something else which is called periodically
  when dragging regions and pulling on menus.)
  Or patch the QD bottlenecks to draw twice (once into your window, once into
  your gDevice). Timbuktu does something like this, except that the second
  draw command is translated to AppleTalk. (NB: You still need the offscreen
  buffer. You're going to have to update the window occasionally...)
  Somewhat more difficult agenda item: copying the pointer bits and making
  sure that nothing is left lying around.
- How to keep said window alive under MultiFinder is left as an exercise to
  the reader. ;-)

< The main thing to do is to simulate 2 different screens on the same
< color screen.  The "Monitors" control panel device would allow you to
< drag the second screen around, relative to the first screen, and
< change the color depth on different screens (probably impossible,
< unless you use some offscreen bitmap trickiness).  You might have to
< allocate 128 color table entries per subscreen.
< 
Color table entries? The thing is going to have the same or fewer colors than
the screen it apears on anyway, so let CopyBits worry about that. ;-)
(Actually, see step three. We'll just let the ROM worry about colors and
stuff. No need to reinvent the wheel.)

< This would be a great boon to people developing software for multiple
< monitors, who can't afford (or don't want to bother) buying a second monitor.

Besides, it would be great fun to actually move a window into another window!

Disclaimer: I am sure that people with more QuickDraw experience can and
            no doubt will find lots of problems with this approach.
Claimer: If I had any spare time in the next few months, I'd write this
         myself, just for the fun of it. Fat chance, however. :-(
-- 
Matthias Urlichs