Subject: Re: Text boxes in Linux
sterwill@abisource.com
Date: Tue Jan 04 2000 - 14:00:15 CST
Ehren von Lehe wrote:
> However, could anyone explain to me why the refresh rate of text boxes in
> Linux seems to be consistently slow (e.g., in Abiword, Netscape, gedit,
> etc.)? I am using a Pentium II laptop with 32 megs of RAM running Red Hat
> 6.1. When holding the down arrow key to scroll, the refresh seems lax in
> almost every application. Is this just because of the machine I am using?
> Is this procedure handled differently in Windows? What could be done to
> improve this?
There are a few reasons you might notice some graphic operations being
slower in X. First off, Windows is insanely optimized for drawing
cases like these. Microsoft programmers have the liberty of writing
time-critical routines in assembly language for Intel processors, something
that would be non-portable. Being tied to local displays only, the
execution path between "drawSomeText("foobar")" and pixels hitting
your screen can be much shorter on Windows. The execution path that
X follows allows for arbitrary re-direction (over the network) at
many levels. This means X has some more overhead.
Also, many vendors hand-tune their video card drivers for Intel chips
(again with assembly when needed) running Windows. Since video drivers
are written to be portable with XFree86 (so that driver code works with
minimal changes on PowerPC, Intel, Alpha, MIPS, and SPARC architectures),
often speed is not the primary concern of the driver author.
There's also the fact that some people write text widget code that's
less efficient than the alternatives. GTK's widgets usually draw
very fast. Notice that AbiWord does not use GTK's text widget for our
document area. If it's slow, it's entirely our problem, and it should
be fixed. The Unix GC has never been optimized for speed, but should be.
I believe it draws much slower than the Windows GC in many cases (almost
all text-related).
For example, it calls "new" for every string draw, which is slow.
This problem would not be too hard to fix (using chunks of statically
allocated RAM), and would probably speed up scrolling and text draws
immensely. You can find this code at abi/src/af/gr/unix/gr_UnixGraphics.cpp,
line 118.
Note that for speed, X does text drawing in the server. That's good,
because client-side drawing (even over local sockets) is very slow.
This is why the server must keep track of font paths.
This isn't to say X is always slow. Well supported cards (like the Matrox
Millennium and G?00 series) are very fast even on machines considered
somewhat slow today (Pentium Pro). Direct rendering architectures (like
what will be in XFree86 4.0, and can be used already on SGI machines,
and maybe Sun machines) can skip the network transport, and let code
essentially call graphics hardware primative routines directly.
-- Shaw Terwilliger
This archive was generated by hypermail 2b25 : Tue Jan 04 2000 - 14:00:17 CST