home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / windows / x / i386unix / 81 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  4.3 KB
  1. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!yale.edu!ira.uka.de!math.fu-berlin.de!mailgzrz.TU-Berlin.DE!gmdtub!bigfoot!tmh
  2. From: tmh@keks.first.gmd.de (Thomas Hoberg)
  3. Newsgroups: comp.windows.x.i386unix
  4. Subject: Re: 32K or 16M colours?
  5. Message-ID: <TMH.92Dec20235423@keks.first.gmd.de>
  6. Date: 20 Dec 92 22:54:23 GMT
  7. References: <linda.724803368@minnie> <1992Dec20.000426.21774@cbnewsj.cb.att.com>
  8. Sender: news@bigfoot.first.gmd.de
  9. Organization: GMD-FIRST, Berlin
  10. Lines: 78
  11. In-reply-to: dwex@cbnewsj.cb.att.com's message of 20 Dec 92 00:04:26 GMT
  12.  
  13. In article <1992Dec20.000426.21774@cbnewsj.cb.att.com> dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
  14.    In article <linda.724803368@minnie> linda@cs.su.oz.au (Linda Distributed Language) writes:
  15.    > Is anybody working on X servers for cards which display 32K or 16M colours,
  16.    > like the 2theMax et4000 based card and other extended et4000 cards?
  17.    > (the 2theMax will do up to 1280x1024x16, 1024x768x256, 800x600x32K)
  18. [...]
  19.    Here's what I know about it:
  20.  
  21.        1) The cfb code with X11R5 was only tested at 8 bits, and is
  22.           known to need work to make it work with other depths.
  23. I don't know what X11R5 was tested on, but any power of 2 is ok as far
  24. as CFB is concerned. I did an X11R4 port to a 1920x1024 HDTV true
  25. color frame buffer two years ago and started with CFB code. Actually
  26. CFB isn't all that useful for depths greater than 8-Bit, because it
  27. uses some gyriations to avoid extra memory and frame buffer references
  28. and tries to work on as many pixels as possible at the same time. On a
  29. packed pixel true color display that code (which was derived from MFB
  30. where it offers the most significant speed improvement) does more harm
  31. than good.
  32.  
  33.        2) The assembler parts of the frame-buffer code in XFree86 were
  34.           designed for 8-bits, and will also need work.
  35. Definitely, since one of the main reasons for it's existence is the
  36. banked nature of SVGA cards.
  37.  
  38.        3) X11R6 will likely have 8-bit, 16-bit, and 24-bit frame-buffer
  39.           code.
  40. I doubt that it will support banked displays nicely.
  41.  
  42.        4) 24-bit SVGA is going to require a LOT of work (perhaps an
  43.           entire new framebuffer driver), because the 24-bit framebuffers
  44.           on most system (and the Xsun24 code I looked at) assume that
  45.           the 24-bits are aligned on 32-bit boundaries, and the 24-bit
  46.           SVGA's are aligned on 24-bit boundaries (think of the pixel-
  47.           addressing complexities here).
  48. If they are (which I doubt) they would be riciculously slow. Also
  49. since they usually trade resolution for pixel depth that means X on
  50. something like 640x480 (yuck!).
  51.  
  52.        5) The 16- and 24-bit SVGA modes are SLOW (1/2 and 1/3 the speed
  53.           of the 8-bit modes, respectively).
  54. Since they trade resolution for pixel depth, the speed differences
  55. shouldn't be that high (except for horizontal lines).
  56.  
  57. >   I would expect that a 16-bit server could be done by a dedicated group
  58. >   without too much headache (lots of use of the XTEST suite will help :->).
  59. If the SVGAs weren't banked, all it would take is the editing of a
  60. couple of macros and a recompile of CFB (or almost). Even with the
  61. X386 version that came with X11R5 it shouldn't be too much work (no
  62. assembler except for bank switching), although the initialization
  63. stuff would be beyond me (lacking the appropriate documentation).
  64.  
  65. >   The 24-bit stuff is going to be much, much worse.
  66. But only if they really pack those pixels on adjacent addresses. It
  67. would completely break CFB and as you said, the work involved would be
  68. horrendous...
  69.  
  70.    --
  71.    David Wexelblat <dwex@mtgzfs3.att.com>  (908) 957-5871
  72.    AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ  07748
  73.  
  74.    "The meaning of life?  That's simple.  Try to be happy, try not to hurt
  75.     other people, and hope to fall in love."  -- Mallory Keaton
  76.  
  77. I can only underline Thomas Roell's lobbying efforts for VRAM here,
  78. because the deeper frame buffers get, the more important is the
  79. "intelligence" built into VRAMS, which offer special addressing modes,
  80. for replicating bitmap data in a preset color through all color
  81. planes, thus offering monochrome speed for fills (though, alas, not
  82. for copies...).
  83.  
  84. ---
  85. Thomas M. Hoberg   | Internet: tmh@first.gmd.de
  86. 1000 Berlin 41     |           tmh@cs.tu-berlin.de
  87. Wielandstr. 4      |
  88. Germany            | BITNET:   tmh@tub.bitnet 
  89. +49-30-851-50-21   |
  90.  
  91.