Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!stl!stc!datlog!torch!paul
From: paul@torch.UUCP (Paul Andrews)
Newsgroups: comp.windows.x
Subject: Re: X11R2 and color displays
Message-ID: <196@torch.UUCP>
Date: 23 May 88 10:03:39 GMT
References: <2413@polyslo.UUCP> <8805111410.AA00140@EXPO.LCS.MIT.EDU>
Reply-To: paul@torch.UUCP (Paul Andrews)
Organization: TORCH Computers Ltd., Cambridge, United Kingdom
Lines: 33

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.