Re: Performance of XPDF under Cygwin XFree86

[Harold L Hunt <huntharo at msu dot edu>]

Adam,

This is pretty much expected.  The commerical X Server on Windows that you 
mention most likely translates X graphics calls to an equivalent set of GDI 
graphics calls, which allows utilization of that $200 graphics processor you 
bought, whereas Cygwin/XFree86 currently does all drawing to an offscreen 
framebuffer that is stored in system memory with updated regions of the 
offscreen framebuffer occasionally (sometimes frequently) transferred to the 
screen.  Work is progressing on translating X graphics calls to GDI graphics 
cals in Cygwin/XFree86.  Take a look at the temporary SourceForge project 
setup to host the development:
https://sourceforge.net/projects/xoncygwin/

If you compile the server there yourself you'll see that it is actually 
capable of drawing most types of graphics.  However, it uses an even worse 
(but essential) method of dumbing down each graphics call (arcs, circles, 
filled polygons, etc.) into a series of simple horizontal line drawing 
operations, "spans".  As you can imagine, this is very slow.  This 
functionality is essential though, as some X graphics calls do not translate 
cleanly, or at all, to GDI graphics calls.  Thus, once we have the spans 
routines working correctly we can start translating the easier functions, 
such as filled circles.

We expect that the performance of Cygwin/XFree86 with the NativeGDI engine 
will be similar to that of commerical X Servers on Windows, as almost all of 
them use the same method.

Hope that answers your question,

Harold

Adam Gundy <arg@cyberscience.com> said:

> 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.
> 
>