home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!dtix!darwin.sura.net!jvnc.net!yale.edu!ira.uka.de!fauern!lrz-muenchen.de!roell
- From: roell@informatik.tu-muenchen.de (Thomas Roell)
- Newsgroups: comp.windows.x.i386unix
- Subject: Re: 32K or 16M colours?
- Message-ID: <1992Dec22.130619.18414@news.lrz-muenchen.de>
- Date: 22 Dec 92 13:06:19 GMT
- References: <linda.724803368@minnie> <1992Dec20.000426.21774@cbnewsj.cb.att.com>
- <TMH.92Dec20235423@keks.first.gmd.de>
- <1992Dec21.032715.14701@cbnewsj.cb.att.com>
- Sender: news@news.lrz-muenchen.de (Mr. News)
- Organization: Inst. fuer Informatik, Technische Univ. Muenchen, Germany
- Lines: 22
- In-Reply-To: dwex@cbnewsj.cb.att.com's message of Mon, 21 Dec 1992 03: 27:15 GMT
-
- >> If they are (which I doubt) they would be riciculously slow. Also
- >> since they usually trade resolution for pixel depth that means X on
- >> something like 640x480 (yuck!).
- >>
- >Take a look at how the 24-bit SVGA's are implemented. Packed 3-byte pixels.
- >It's going to make working on them rediculous.
-
- I don't think 3byte pixels is that rediculus if you look at the memory
- contraints given in todays SVGAs. But the price to pay is VERY high.
- You can only deal with 24bpp (opposed to 32bpp) by using 32bit
- reads/writes. A simple statistic shows that about every second access
- will be not correctly aligned and hence at least 2 32bit accesses to
- video memroy will be necessary. Having this in mind a 24bpp
- framebuffer will be at leat 1.5 times slower than a 32bpp. This is
- really a mess ...
-
- - Thomas
- --
- -------------------------------------------------------------------------------
- Das Reh springt hoch, e-mail: roell@sgcs.com
- das Reh springt weit, #include <sys/pizza.h>
- was soll es tun, es hat ja Zeit ...
-