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