home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / amiga / programm / 11454 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.0 KB
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!mips!apple!apple!netcomsv!terapin!paulk
  2. From: paulk@terapin.com (Paul Kienitz)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: MakeScreen(); RethinkDisplay() vs. MakeVPort(); MrgCop(); LoadView()
  5. Message-ID: <paulk.0ucw@terapin.com>
  6. Date: 22 Jul 92 02:31:14 GMT
  7. References: <1b5c1b9e.ARN5a25@moria.UUCP>
  8. Organization: BBS
  9. Lines: 47
  10.  
  11. > Paul Kienitz recently (on July 5) claimed that the following code:
  12. > 
  13. >       MakeScreen(screen);
  14. >       RethinkDisplay();
  15. > 
  16. > could be replaced with:
  17. > 
  18. >       MakeVPort(&IntuitionBase->ViewLord, &screen->ViewPort);
  19. >       MrgCop(&IntuitionBase->ViewLord);
  20. >       LoadView(&IntuitionBase->ViewLord);
  21. > 
  22. > without any Intuition compatibility problems whatsoever.
  23.  
  24. That I had experienced.  I have since heard of several people having
  25. trouble, though.
  26.  
  27. > The code violates
  28. > the rule that you should lock IntuitionBase while mucking with the fields.
  29. > So a more correct method would appear to be this:
  30. > 
  31. >       ULONG iBaseLock = LockIBase(0);
  32. > 
  33. >       MakeVPort(&IntuitionBase->ViewLord, &screen->ViewPort);
  34. >       MrgCop(&IntuitionBase->ViewLord);
  35. >       LoadView(&IntuitionBase->ViewLord);
  36. >       UnlockIBase(iBaseLock);
  37. > 
  38. > and indeed I haven't managed to crash my machine with this code yet
  39.  
  40. I think when I posted it I had the stuff inside a Forbid().  Is that
  41. an adequate substitute for LockIBase?  Maybe those who got crashes
  42. didn't Forbid.  LockIBase is clearly a more optimal approach though,
  43. if it really works.
  44.  
  45. Now the question is, if this DOES really work, why the heck is
  46. RethinkDisplay so damn slow?????
  47.  
  48. > Now I wonder whether this method is endorsed at all by Commodore.
  49. > My hunch is that it isn't, but I would like to hear the official
  50. > word on this :-)
  51.  
  52. Me too.
  53.  
  54. Note that it was not me who originally suggested it -- I was just repeating
  55. someone else's suggestion which had worked for me -- sped up my little program
  56. enough to put back in some WaitTOFs which had been taken out because
  57. RethinkDisplay was slow enough to eat a whole frame.
  58.