Path: utzoo!attcan!uunet!husc6!mit-eddie!fenchurch.mit.edu!jbs
From: jbs@fenchurch.MIT.EDU (Jeff Siegal)
Newsgroups: comp.windows.x
Subject: Re: Optimizing around the server
Message-ID: <9896@eddie.MIT.EDU>
Date: 18 Aug 88 03:00:13 GMT
References: <5058@pasteur.Berkeley.EDU>
Sender: uucp@eddie.MIT.EDU
Reply-To: jbs@fenchurch.MIT.EDU (Jeff Siegal)
Organization: MIT EE/CS Computer Facilities, Cambridge, MA
Lines: 26

In article <5058@pasteur.Berkeley.EDU> dheller@cory.Berkeley.EDU (Dan Heller) writes:
>our desk top publishing package will use XCopyArea
>to render our fonts (held in pixmaps).  [...]
>the performance is typically pretty bad because there is a XCopyArea
>done for each character on the page.
>[...]
>If a particular server's XCopyArea is slow,
>then it's out of our hands, right?  Or am I just passing the buck?

I definitely agree.  Sending the full image as data for each page drawn
is a *lot* more data than necessary, and will certainly slow to a
crawl if you are talking to the server over a network, or even on a
machine with slow IPC.

There is probably no reason for pixmap-to-window CopyArea to be slow,
other than inefficient server code.  

I don't know which servers have slow CopyArea code, but I recently
worked on optimizing the server for the DEC QVSS, which uses the mfb
library.  The original CopyArea (for pixmap to windows copies) created
(i.e. allocated from the heap) several Region structures, did two (or
so) IntersectRegion calls, then destroyed the regions.  Cleaning this
up, along with slightly optimized BitBlt code, improved the
performance by a factor of 3 for small pixmaps.

Jeff Siegal