home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / mac / programm / 21269 < prev    next >
Encoding:
Text File  |  1993-01-12  |  2.9 KB  |  66 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!mcsun!news.funet.fi!funic!nntp.hut.fi!vipunen.hut.fi!jmunkki
  3. From: jmunkki@vipunen.hut.fi (Juri Munkki)
  4. Subject: Re: Direct screen writing; getting to (x,y)
  5. Message-ID: <1993Jan12.101446.14441@nntp.hut.fi>
  6. Sender: usenet@nntp.hut.fi (Usenet pseudouser id)
  7. Nntp-Posting-Host: vipunen.hut.fi
  8. Reply-To: jmunkki@vipunen.hut.fi (Juri Munkki)
  9. Organization: Helsinki University of Technology
  10. References: <1993Jan11.235448.22675@afterlife.ncsc.mil> <1993Jan12.021320.7406@nntp.hut.fi> <1993Jan12.081850.12759@afterlife.ncsc.mil>
  11. Date: Tue, 12 Jan 1993 10:14:46 GMT
  12. Lines: 52
  13.  
  14. In article <1993Jan12.081850.12759@afterlife.ncsc.mil> mssmith@afterlife.ncsc.mil (M. Scott Smith) writes:
  15. >What would be the easiest way to handle different
  16. >bit depths?  My primary concern for now is 8-bit.
  17.  
  18. Since only 1, 2, 4, 8, 16 and 24-bit are used by the Macintosh (for now),
  19. it's fairly easy to implement them all separately. For more complicated
  20. things than point-plotting, a bottleneck function works or you can use
  21. the bitfield instructions in the 68020 (which means you have to write asm).
  22.  
  23. >> Of course, it doesn't really work. It only works on some hardware, but
  24. >> it will cause big problems with a lot of machines.
  25. >
  26. >   Is my new routine a bit more friendly, or does it still have a problem?
  27.  
  28. It's mainly the lack of SwapMMUMode that will cause problems.
  29.  
  30. >>     SwapMMUMode
  31. >> and ShieldCursor
  32. >
  33. >   I haven't messed with ShieldCursor before, so I'll look into that.  I
  34. >assume I should be calling SwapMMUMode in my PlotPoint function, right
  35. >before and after I do the plot.  Does this eat up much processor time?
  36.  
  37. Yes, it does take quite a bit of CPU time, so you should plot as many
  38. points as possible between the calls to SwapMMUMode.
  39.  
  40. >> This works as long as no one changes the screen resolution suddenly. It
  41. >> usually doesn't happen, but I think it's possible under some circumstances.
  42. >
  43. >   Someone would do that??  How rude.  :)  Would the best strategy be to
  44. >periodically check the depth of the screen you're working with, like in the
  45. >event loop, and then to do whatever's necessary if the bit depth suddenly
  46. >changes?  (Like maybe put up a dialog that say "hey, don't do that!", or
  47. >re-compute everything.)
  48.  
  49. I wasn't really talking about screen depth: that's done all the time and
  50. it gives you a nice update event and probably always also changes the ctSeed
  51. of that device. It's fairly easy to detect depth changes and adapt to them.
  52.  
  53. I was mainly thinking of those Pivot displays again. I don't know what kind
  54. of magic they do (never having used one), but it would seem to me that they
  55. might change the rowBytes value when the display is rotated. Then again, maybe
  56. they don't.
  57.  
  58. >Well, thanks for all of your information.  It was very helpful.
  59.  
  60. I hope I wasn't too rude. This is getting to be RFAQ and it seems I'm always
  61. repeating this same information.
  62.  
  63. -- 
  64.   Juri Munkki                           Windsurf: fast sailing
  65.  jmunkki@hut.fi                          Macintosh: fast software
  66.