home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2502 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.8 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS friendly part II
  5. Date: 1 Feb 1996 02:30:46 +0100
  6. Organization: dis-
  7. Message-ID: <4ep546$hpr@serpens.rhein.de>
  8. References: <john.hendrikx.47u5@grafix.xs4all.nl>     <PETERM.96Jan29164036@tui.maths.irl.cri.nz>     <4ek6bo$84n@xmission.xmission.com> <4ekl5d$51@serpens.rhein.de> <PETERM.96Feb1123338@tui.maths.irl.cri.nz>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. peterm@maths.grace.cri.nz (Peter McGavin) writes:
  12.  
  13. >Current high-level gfx calls have a queue limit of 1 (or less than 1).
  14.  
  15. Right. But that's as good as N.
  16.  
  17. >BTW: What is the correct way of waiting for an async gfx operation to
  18. >complete?
  19.  
  20. There is no correct way :-(
  21.  
  22. The best approximation is WaitBlit() and that is used everywhere. Using
  23. WaitBlit() for synchronization is a BIG obstacle on the way towards RTG.
  24.  
  25. >One could use OwnBlitter()/WaitBlit()/DisownBlitter(), but
  26. >it's not always clear whether the blitter is used.
  27.  
  28. WaitBlit() works without owning the blitter.
  29.  
  30. >I agree.  However task switches are not a problem for large gfx
  31. >operations like copying an entire bitmap.
  32.  
  33. Right. I am thinking of a flexible solution that queues blit nodes
  34. for large blits.
  35.  
  36. >This is akin to a large IO
  37. >request in DOS.  Perhaps the system should have a mechanism for
  38. >batching trivial gfx operations, something like buffered IO in DOS.
  39.  
  40. All you need is a proper model for synchronization. This should be
  41. done on either a bitmap or a rastport basis. Graphic operation can then
  42. be completely asynchronous as the driver decides.
  43.  
  44. Regards,
  45. -- 
  46.                                 Michael van Elst
  47.  
  48. Internet: mlelstv@serpens.rhein.de
  49.                                 "A potential Snark may lurk in every tree."
  50.