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