Path: utzoo!attcan!uunet!husc6!think!ames!ucsd!ucsdhub!hp-sdd!megatek!corona!rgs From: rgs@corona.megatek.uucp (Rusty Sanders) Newsgroups: comp.windows.x Subject: Re: Color on Suns Message-ID: <368@megatek.UUCP> Date: 16 Aug 88 17:43:47 GMT References: <8808152051.AA00237@devnull.sun.com> Sender: news@megatek.UUCP Lines: 60 From article <8808152051.AA00237@devnull.sun.com>, by dshr@SUN.COM (David Rosenthal): >> >> I also have a question about how the Sun server is implemented: >> Does it use pixrect calls for all of the graphic operations ? >> If not, where are all of the low level routines that write to the frame >> buffer. I have been looking under server/ddx/sun for the source that >> does this, but I am a little confused. >> > All the code to drive all Sun displays by treating them all > as memory is contained in the directories ddx/sun, ddx/mi, > ddx/mfb, and ddx/cfb. The fact that the server treats all > Sun displays as memory, without using the hardware ROP > support, is part of the reason why it is slow on color Suns. > No pixrect code is used at all. > > David. I disagree with the statement that the sun server needs to use pixrect and the hardware rop operations to get good performance. I've taken the current color server (which is practically unusable with it's current performance) and played with it a little bit. I have used no pixrect or hardware rop operations. In my examination of the code practically all of the operations to memory really need to be just source rop operations. It doesn't take much hardware to do that. The problem with the sun performance isn't that it's not using the hardware avaiable, it's that the cfb code is really really slow. I've reimplmented the sections of code that I cared about. Mostly that means I spent a lot of time on glyph generation, area copy (scrolling et al), and line generation. My glyphs now run about 16-20 times faster then the old terminal emulator code (cfbTEGlyphBlt), and only about 1/2 as fast as the mono code. The other glyph stuff runs about 60 times faster, since the cfb code uses the mi layer for clipped TE glyphs and for poly glyphs. Solid fill is sped up by about a factor of 10, scrolling and region move by a factor of 2 to 8 (just too many bits to move around). After all these changes the sun server is actually quite nice to use on a color monitor. And note I haven't had to use any sun specific functions, so the code could be made just as portable as the current cfb code. Note that last statement, the code is currently rather non portable. I don't take into account bit or byte order, and I tended to be lazy in places about word and pixel sizes and depths. It wouldn't be too hard to fix up tho. Unfortunatly, don't ask me to send the stuff out right now. The code is being used on Megatek's new workstation's implementation of X, and we're not releasing the code right now. Maybe later. In any case, the point is that the cfb code isn't slow because it doesn't use pixrects. It's slow because it's really stupid (altho portable and easy to implement). It also doesn't eat up much memory (I "threw memory at the problem" to get some performance, especially with glyphs). I'm trying to get permission to send my improvements, but it won't be soon (if at all). But it's just not true that to get X performance on a sun you have to use pixrects. In fact, I can probably get better performance without it just by useing good code. Rusty Sanders, Megatek Corp. --> rgs@megatek or... ...ucsd! ..hplabs!hp-sdd!megatek!rgs ...ames!scubed!