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!