Performance of XPDF under Cygwin XFree86

[Adam Gundy <arg at cyberscience dot com>]

Hi...

I've just noticed that using XPDF with Cygwin XFree86 maxes
out the processor on the X server box (ie XFree86), and leaves the
actual XPDF program using almost zero CPU time. Redrawing the current
window after it has displayed is instant.

The result is that XPDF is very slow to use, with 2 or 3 second drawing
times for each page... Using XVision server instead of XFree86 does not
give these symptoms - new pages are rendered much faster, XVision uses very
little CPU, XPDF uses more.

I've done some packet sniffing using ethereal, and XPDF appears to be making
the following sequence of Xlib calls a lot of times for each page (characters
I guess)

while ( rendering )
{
    XQueryColors: pixels_item: 0x0000ffff
    XPutImage: ZPixmap, width = 6, height = 4, depth=16, xpos = 400 ypos = 400
    XGetImage: ZPixmap, width = 6, height = 4, depth=16, xpos = 406 ypos = 400
}

The XPutImage/XGetImage calls are sent in a single packet.
The XQueryColors call is very wasteful - it seems to be asking about the 
same color
every time. This appears to be a bug in the anti-aliased font rendering of 
t1lib -
you can turn it off by starting XPDF with the "-t1lib plain" option, but it 
doesn't
seem to improve the performance at all.

The only differences when run on XVision is that the pixel depth is 24 (XVision
pretends to be 24 bit truecolor in 16 bit modes).

I've also tries x11perf -getimage10, XFree86 achieves 590 GetImage 10x10 
(with 100% CPU),
XVision 1140 (with minimal CPU) (ie XVision is almost twice as fast!)

x11perf -putimage10, XFree86 achieves 4890 PutImage 10x10 (with 100% CPU),
XVision 2590 (minimal CPU) (ie XFree86 is almost twice as fast!)

It looks like XGetImage() could do with some optimisation...


Seeya,
  Adam
--
Real Programmers don't comment their code. If it was hard to write,
it should be hard to read, and even harder to modify.
These are all my own opinions.