schultz@mmm.UUCP (John C Schultz) (05/10/88)
I recently got X11R2 to work with GNU EMACS (18.50.1) on my SUN 3/60C
(4 MB RAM, SunOS 3.5) as a /dev/cgfour. (Thanks to everyone on the
net who answered my questions and provided patches.)
Now that I can use color displays I have noticed that the display rate
is much slower than for the B&W driver. For example repainting the
screen in an EMACS window looks to be at most 9600 baud whereas on a
B&W X window, the display basically "flashes" up.
Is this a problem with my installation of X/GNU EMACS and/or a problem
with X11R2?
BTW, my mouse does not slide off any side of the /dev/cgfour display to
toggle between B&W and color displays.
john c. schultz {umn-cs, ems, tundra}!mmm!schultz
------or------ schultz@mmm.UUCP
The opinions expressed herein are, as always, my own and not 3M's.
Surface mail: 3M Center, AT&T:(612) 733-4047
Bldg. 518-1-1
St. Paul, MN 55144-1000jeff@polyslo.UUCP (Skippy The Wonder Hacker) (05/11/88)
The color X11 implementation provided by Sun to MIT is a real dog. This is probably due to the fact that Sun is expending effort on their X11/NeWS product, which they will charge for. The slowness you are seeing is entirely due to the poorly performing server. Jeff Weinstein Computer Systems Lab Cal Poly State Univ. jeff@polyslo.uucp ucbvax!voder!polyslo!jeff
ndd@duke.cs.duke.edu (Ned Danieley) (05/11/88)
In article <786@mmm.UUCP> schultz@mmm.UUCP (John C Schultz) writes: > >BTW, my mouse does not slide off any side of the /dev/cgfour display to >toggle between B&W and color displays. > >john c. schultz {umn-cs, ems, tundra}!mmm!schultz The only way that I've been able to do this is by running X on top of suntools, after using switcher(1) or adjacentscreens(1). Is this supposed to be doable directly from X? Ned Danieley (ndd@sunbar.mc.duke.edu) Basic Arrhythmia Laboratory Box 3140, Duke University Medical Center Durham, NC 27710 (919) 684-6807 or 684-6942
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (05/11/88)
> The slowness you are > seeing is entirely due to the poorly performing server. Let's clarify this a bit. The "poorly performing" part refers to the fact that the ddx for that device uses the generic Color Frame Buffer code instead of hardware support, just as the qvss/vs2000 server uses the generic Monochrome Frame Buffer code. Servers based on cfb are slower than ones that use mfb because they have to do a LOT more work (color pixels typically have 4, 8, or many more times the number of bits that monochrome pixels have). It ought to be relatively easy for someone who knows the low-level graphics libraries of the machine to optimize many of the more common operations (solid and tiled filled rectangles, solid text, copy area, lines, etc.). Do I hear any volunteers? Jim Fulton MIT X Consortium
paul@torch.UUCP (Paul Andrews) (05/23/88)
In article <8805111410.AA00140@EXPO.LCS.MIT.EDU> jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes: > >> The slowness you are >> seeing is entirely due to the poorly performing server. > >Let's clarify this a bit. The "poorly performing" part refers to the fact that >the ddx for that device uses the generic Color Frame Buffer code instead of >hardware support... >...Jim Fulton You don't need hardware support to improve the performance of the generic Colour Frame Buffer code. Take a look at cfbbitblt.c for starters. You'll find just one special case in there. This case goes reasonably quickly (although even that could be improved) but ALL the other cases use the same code. By special casing these a large improvement in performance could be gained. Another area to look at - one I haven't looked at yet - is special-casing of text writing. As I have said. I don't know what this code is doing yet, but the basic problem is that the fonts are all single bit-plane whilst the destination is multi-bit-planed. This means that pixel expansion has to take place. This is VERY slow. Caching of expanded font pixmaps may improve things if this isn't already done. Finally, as the documentation says, fat line drawing uses floating point DDA's. A little application of Bresenham may help here. Over the coming months we'll be investigating all these areas. P.S. As the documentation implies the generic cfb code isn't so generic. If you use anything other than 8 bits per pixel you'll have quite a few changes to make. Some are just hard-coded 8's, some are algorithm changes, some are bug-fixes. Generally though its pretty good and the changes shouldn't take more than a week or so from start to finish. - Paul.
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (05/28/88)
> You don't need hardware support to improve the performance of the generic > Colour Frame Buffer code. Of course. However, you still won't approach the speed in which this could be done in hardware. We'll gladly accept any fixes and optimizations! Jim