dheller@cory.Berkeley.EDU (Dan Heller) (08/17/88)
At Island, we have a bunch of products we're developing/porting to X. As you can imagine, we do lots of graphics. However, one problem we're running into is the server on which our application is run may significantly impact performance. For example, our desk top publishing package will use XCopyArea to render our fonts (held in pixmaps). To display a whole page, the performance is typically pretty bad because there is a XCopyArea done for each character on the page. Someone suggested that we just use internal "pixmap" type data structures and keep them on the client rather than the way X does it (keep them on the server) and do our own rendering into those pixmaps and when it finally needs to be displayed, just use one XCopyArea to get it onto the screen. The feeling is that any communication with the server is expensive because of 1) protocol is slower than just keeping the data resident on the client, or 2) sending that many bits over the wire is intrinsically slow especially if you multiply the amount of data and header info transfered by the number of requests that go back and forth. Being a graphics company we have a large library of pretty impressive and optimized graphics routines. Doing this stuff on the client seems to be "logical." Because our applications run on many different types of hosts, we're not about to try to optimize any particular server... What's more, it's not our responsibility to the client to provide "server" support and/or optimization. Our clients write their own servers, but the feeling here (internally) is that since we have all these great graphics routines, we'd like to try to optimize the code as best we can on the client and avoid the server as much as possible. I am dubious about this frame of mind. I'm undecided about whether or not this is a good idea because something tells me that the "server" is there for a reason and avoiding it really isn't the right thing to do [conceptually]. If a particular server's XCopyArea is slow, then it's out of our hands, right? Or am I just passing the buck? Dan Heller <island!argv@sun.com>
swick@ATHENA.MIT.EDU (Ralph R. Swick) (08/17/88)
> Because our applications run on many different types of hosts, > we're not about to try to optimize any particular server... What's > more, it's not our responsibility to the client to provide "server" > support and/or optimization. Absolutely correct. Market pressures will encourage workstation vendors to improve the performance of their software (i.e. the X server) and hardware. "Customers" of all types should make a fuss rather than quietly accept the foibles of something for which they've paid good money. This doesn't rule out the possibility that a particular sequence of operations might be more efficiently performed on the client side, either because of special algorithms, special hardware, or a different compute engine available to the client.
Kimbrough@dsg.csc.ti.COM (Kerry Kimbrough) (08/18/88)
> For example, our desk top publishing package will use XCopyArea > to render our fonts (held in pixmaps). To display a whole page, > the performance is typically pretty bad because there is a XCopyArea > done for each character on the page. Perhaps what you'd really like would be a way to make your proprietary fonts available to X servers for use in servicing Poly/ImageText requests. That is, a standard font format file for X. How about it, X Consortium? On the other hand, if you need to render text in certain ways that are unknown to the X protocol (e.g. anitaliased), you may be forced to rely upon generating and copying images. Some of the trade-off of doing this client-side or server-side seem to be: Client-side Server-side ------------------------------------------------------------------------------------ My graphics code is fast vs. The server hw can draw to off-screen pixmaps. I've got lots of memory or my paging vs. The server's got lots of memory is fast or its paging is fast. The number of graphics requests to vs. The number of graphics requests create the pixmap image is large w.r.t to create the pixmap image is the equivalent PutImage request small w.r.t the equivalent PutImage request.
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/18/88)
Date: Wed, 17 Aug 88 14:05:27 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
That is, a
standard font format file for X. How about it, X Consortium?
There is a good file format for font interchange: BDF. It's documented
in the release, in doc/bdf.PS. I would encourage server vendors to
provide compilers that convert BDF to whatever native format their
server wants. Trying to standardize on a native format is probably a
lot harder, because people want the freedom to make that format
correspond to what their hardware wants to do, and also make it fast to
load.jbs@fenchurch.MIT.EDU (Jeff Siegal) (08/18/88)
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
jbs@fenchurch.MIT.EDU (Jeff Siegal) (08/18/88)
Also, turning off GraphicExpose events before doing the pixmap-to-window CopyArea might help. Jeff Siegal
harry@hpcvlx.HP.COM (Harry Phinney) (08/19/88)
> I am dubious about this frame of mind. I'm undecided about whether > or not this is a good idea because something tells me that the "server" > is there for a reason and avoiding it really isn't the right thing > to do [conceptually]. If a particular server's XCopyArea is slow, > then it's out of our hands, right? Or am I just passing the buck? > Dan Heller <island!argv@sun.com> I agree. Beat on the server supplier until they improve the performance. Doing PutImages instead of CopyAreas is foolish in the long run. Harry Phinney