home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / amiga / graphics / 7382 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  2.8 KB

  1. Xref: sparky comp.sys.amiga.graphics:7382 comp.sys.amiga.programmer:15760
  2. Path: sparky!uunet!utcsri!newsflash.concordia.ca!mizar.cc.umanitoba.ca!ciit85.ciit.nrc.ca!brandonu.ca!brycerw
  3. Newsgroups: comp.sys.amiga.graphics,comp.sys.amiga.programmer
  4. Subject: Re: OS3.0: does this have to use Chip ram?
  5. Message-ID: <1992Nov12.121428.1@brandonu.ca>
  6. From: brycerw@brandonu.ca
  7. Date: 12 Nov 92 12:14:28 CST
  8. References: <BxK58F.24J@fc.hp.com> <lg3bmfINNn0u@peaches.cs.utexas.edu>
  9. Organization: Brandon University, Brandon, Manitoba, Canada
  10. Nntp-Posting-Host: stan.brandonu.ca
  11. Lines: 43
  12.  
  13. In article <lg3bmfINNn0u@peaches.cs.utexas.edu>, bryan@cs.utexas.edu (Bryan Bayerdorffer) writes:
  14. > In article <BxK58F.24J@fc.hp.com> koren@fc.hp.com (Steve Koren) writes:
  15. > =-
  16. > =-So it occurred to me that this scheme might be workable:
  17. > =-
  18. > =-   Bitmaps for the workbench screen itself:    CHIP
  19. > =-   Bitmaps for the IFF backdrop images    :    FAST
  20. > =-
  21. > =-The idea is that only the screen's bitmaps _really_ have to be in chip
  22. > =-RAM, because they are the only ones displayed.  The IFF backdrop bitmaps
  23. > =-are never displayed directly; they are just used to copy parts of back
  24. > =-into the screen's bitmap.  If one is willing to use the CPU to do this
  25. > =-copy instead of the blitter, then why couldn't the IFF backdrop image
  26. > =-planes be stored in fast RAM?  I have boatloads of fast RAM to allocate
  27. > You could ask that question about any concealed portion of a bitmap.  It's a
  28. > fine idea, and would be a good way to implement SMART_REFRESH windows,
  29. > especially with a fast processor, and maybe dual-ported chip RAM.  I'd say that
  30. > Intuition doesn't do this for SMART_REFRESH windows, and Workbench doesn't do
  31. > this for its SIMPLE_REFRESH window, because they're aimed at the
  32. > lowest-common-denominator system with a 7MHz 68000 and 16-bit-wide chip RAM,
  33. > which would be killed by this scheme.  Hell, even Nickprefs keeps its WB picture
  34. > in chip RAM.
  35. > Still, there otter be a config option that tells the system which way to do it.
  36. > Anyone want to reimplement layers.library?
  37. > Now get back to work on SKsh, Steve.  I want my $FG_PRI.   :-)
  38.  
  39. Then there are those of us who need *large* bitmaps for only internal
  40. rendering, then copy only a portion out to be displayed.  It'd be great if I
  41. could store a completely compatible bitmap in fast ram, then copy a portion of
  42. it to a displayable bitmap in chip ram.  Right now, I've made up my own 
  43. FastBitMap structure and use Read/WritePixelArray8() to move data to/from 
  44. fast ram and chip ram.  This is in an attempt to allow bitmapped images
  45. too large for chip ram, but will fit in fast ram, to exist.  Could someone 
  46. from Commodore let us know if a standard (but not displayable) bitmap is now 
  47. possible in fast ram, under 3.0?  Also, does BitMapScale() always use the
  48. blitter?
  49.  
  50. --Rob    - needing lots of large (2000X2000) bitmaps
  51.