Issue 6044 - General GUI performance very slow, especially on remote X server
Summary: General GUI performance very slow, especially on remote X server
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 1.0.0
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: OOo 1.1.1
Assignee: philipp.lohmann
QA Contact: issues@gsl
Depends on:
Reported: 2002-06-21 18:53 UTC by Unknown
Modified: 2004-06-29 04:11 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

xdpyinfo output for machine which is very slow (1.96 KB, text/plain)
2003-01-13 20:13 UTC, dan
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Unknown 2002-06-21 18:53:02 UTC
Platform: Linux
Distribution:  Mandrake 8.1

The overall GUI performance is painfully slow.  This is especially noticable
over remote X11.  For example, menus from the menu-bar can take as long as 
3-4 seconds to open.

I realize that some would consider this a performance "enhancement" as 
opposed to a "defect", but given the popularity of OO, especially on the 
Linux/Unix platform, where remote X11 is commonly used, such poor performance 
should be considered a serious problem (IMHO).
Comment 1 Frank Schönheit 2002-07-09 15:20:41 UTC
changing component and QA contact to gsl: if at all, this is a problem
of the graphics system layer.
Comment 2 philipp.lohmann 2002-07-10 12:19:48 UTC
Please give more details. For example the menus: do you mean the first
time opening them (which is quite slow IMHO, but has nothing to with
the GUI but with the code that fills the menu items) or every time.
What else do you consider slow about the GUI ? Do you have render
extension enabled, which improves things dramatically (though you say
you use Mandrake 8.1 suggesting that you use XFree with render enable).
Comment 3 dan 2003-01-13 20:12:39 UTC
I have also the same troubles as are described in this bug.

I have installed ltsp, the server is P4/2,4 GHz, 512MB RAM, IDE disks,
but with 8MB cache. Client is Duron 850, VGA card with 64 MB RAM,
Xfree 4.2.

All applications are fast enought. Mozilla, gimp, KDE, acrobat,

Network is switched full duplex 100. Only five machines in testing

But OOo also has big problems with menu drawing. I have tried versions
1.0.1 and devel build 643. It takes over 1 second to open the menu. No
important if it is first open, or second. First time is it slower, but
not match than second time. OOo send many requests to the Xserver
while working with menu.

I will also attach xdpyinfo command output.

It seems, that OOo forces Xserver to load somethink repeatly over nfs,
when are the X running from local harddrive, the performance is match
Comment 4 dan 2003-01-13 20:13:54 UTC
Created attachment 4288 [details]
xdpyinfo output for machine which is very slow
Comment 5 Unknown 2003-01-15 00:05:09 UTC
I have emailed a little with Dan, and also can reproduce this. My
tests show that remotely running OO (both directly or forwarded by
ssh) can trigger something that causes X to eat excessive amounts of
CPU (yes, during those 2-3 seconds the menu gets drawn, X eats all
CPU). I am not sure what it is, because I only can reproduce on one
machine (surprisingly the fastest among the tested), and that one
isn't even a X-terminal. I have been using this machine extensively
for over 3 years and never noticed something like this before.

MfG shurdeek
Comment 6 h.ilter 2003-03-06 16:48:55 UTC
Linux staff.
Comment 7 ulf.stroehler 2003-03-06 17:10:09 UTC
You should know that AntiAliasing especially on remote displays has
massive performance drawbacks. Try disabling AA when working with OO
on remote displays is slow. You should also have RENDER enabled when
working with current XFree versions (grep for RENDER in xdpyinfo to
see if it is enabled). RENDER gives a performance boost for rendering
glyphs. Notably with complex asian glyphs.

US->JA: could you pls. comment on this performance issue from your
point of view.
Comment 8 2003-03-07 12:25:49 UTC
I see that XRender is available on the system so working with  
remote X11 should have decent performance. I'd love to know where  
the XServer spends it's time...  
Can you also attach the XFree output (typically  
Comment 9 2003-03-07 12:27:49 UTC
Additionally it would be interesting to know where the scalable font 
files are. Are they on a network filesystem? 
Comment 10 Joost Andrae 2003-03-10 11:32:55 UTC
Joost->Fred: please provide information about the platform and the X
server in use of the remote DISPLAY. Did you really use XFree86 or did
you use a thin client which doesn't have the RENDER extension available ?

JA->HDU: as discussed I send this issue for further evaluation to you.
As you can remember we were once able to do rendering on a remote
display with RENDER extension available but I can remember we had
problems with RENDER extensions on XSun when remotely displayed on a
SunRay. I set Beta2 as target. Lets have a look at it together after
03/24/2003 when I'm back from CeBIT/OOo conference.
Comment 11 Unknown 2003-03-11 21:24:07 UTC
Sorry for not responsing faster, I somehow forgot but now I'm back.

Yes, I use XFree86 on thin clients, no weird X. Version between 4.2.0
and I can't find a safe way to reproduce this on all
computers, but it looks like it happens at least on mach64 and sis530/620.

Whether fonts are remote doesn't matter, because I can also reproduce
this with a non-thin-client, just a normal notebook when running OO
remotely. Moreover, it isn't xfs which eats the CPU, but X (so says top).

Both sis and mach64 have RENDER extensions and have also no
performance problems with antialiased fonts.

A weird thing I just noticed is that the following appears repeatedly
on the console on my sis when the OO drawing becomes slow (I assume X
reports this, but oddly it isn't in XFree86.log.0):

parse error: line 879 of stdin
Errors encountered in stdin; not compiled.

The server and thin clients run RedHat 7.2 (only init script of thin
clients is modified). I use a thin client as my main workstation now,
and so far I only noticed this behaviour with openoffice. For a hint
about performance of the machines, I can view flash animations in
mozilla and even run xawtv from another machine without any weird

It seems not only to happen with menus, but when displaying text in
general (e.g. opening a document or scrolling in a document).

I have OO 1.0.1 but am downloading 1.0.2 and will try it out.

MfG shurdeek
Comment 12 2003-03-14 13:22:57 UTC
> I have OO 1.0.1 but am downloading 1.0.2 and will try it out. 
I'm very interested in the results. 
Comment 13 Unknown 2003-03-27 16:29:46 UTC
Well, I installed 1.0.2 and now I finally have antialiased fonts.
Surprisingly, there is no problem anymore with scrolling, although it
should actually consume more CPU, because the documents fonts are
antialiased. But menus are still slow as hell (and non-antialiased).

Comment 14 2003-04-04 12:55:22 UTC
I have the suspicion that stippled XFillRectangle on your X server is slow. 
Could you please run 
x11perf -srect10 -srect100 -oddsrect10 -oddsrect100 
on this remote connection and report the results? 
Comment 15 Unknown 2003-04-29 11:35:23 UTC
I ran the test and it seemed to work pretty fast, here are the results :

x11perf - X11 performance program, version 1.5
The XFree86 Project, Inc server version 40299002 on mireille:0.0
Tue Apr 29 12:23:29 2003

Sync time adjustment is 1.2801 msecs.

 500000 reps @   0.0095 msec (105000.0/sec): 10x10 stippled rectangle
(8x8 stipple)
 500000 reps @   0.0089 msec (113000.0/sec): 10x10 stippled rectangle
(8x8 stipple)
 500000 reps @   0.0090 msec (111000.0/sec): 10x10 stippled rectangle
(8x8 stipple)
 500000 reps @   0.0098 msec (102000.0/sec): 10x10 stippled rectangle
(8x8 stipple)
 500000 reps @   0.0080 msec (125000.0/sec): 10x10 stippled rectangle
(8x8 stipple)
2500000 trep @   0.0090 msec (111000.0/sec): 10x10 stippled rectangle
(8x8 stipple)

  14400 reps @   0.3775 msec (  2650.0/sec): 100x100 stippled
rectangle (8x8 stipple)
  14400 reps @   0.3579 msec (  2790.0/sec): 100x100 stippled
rectangle (8x8 stipple)
  14400 reps @   0.3579 msec (  2790.0/sec): 100x100 stippled
rectangle (8x8 stipple)
  14400 reps @   0.3485 msec (  2870.0/sec): 100x100 stippled
rectangle (8x8 stipple)
  14400 reps @   0.3451 msec (  2900.0/sec): 100x100 stippled
rectangle (8x8 stipple)
  72000 trep @   0.3574 msec (  2800.0/sec): 100x100 stippled
rectangle (8x8 stipple)

 600000 reps @   0.0085 msec (118000.0/sec): 10x10 stippled rectangle
(17x15 stipple)
 600000 reps @   0.0076 msec (132000.0/sec): 10x10 stippled rectangle
(17x15 stipple)
 600000 reps @   0.0097 msec (103000.0/sec): 10x10 stippled rectangle
(17x15 stipple)
 600000 reps @   0.0083 msec (121000.0/sec): 10x10 stippled rectangle
(17x15 stipple)
 600000 reps @   0.0089 msec (113000.0/sec): 10x10 stippled rectangle
(17x15 stipple)
3000000 trep @   0.0086 msec (116000.0/sec): 10x10 stippled rectangle
(17x15 stipple)

  21600 reps @   0.3227 msec (  3100.0/sec): 100x100 stippled
rectangle (17x15 stipple)
  21600 reps @   0.3049 msec (  3280.0/sec): 100x100 stippled
rectangle (17x15 stipple)
  21600 reps @   0.3081 msec (  3250.0/sec): 100x100 stippled
rectangle (17x15 stipple)
  21600 reps @   0.3224 msec (  3100.0/sec): 100x100 stippled
rectangle (17x15 stipple)
  21600 reps @   0.2983 msec (  3350.0/sec): 100x100 stippled
rectangle (17x15 stipple)
 108000 trep @   0.3113 msec (  3210.0/sec): 100x100 stippled
rectangle (17x15 stipple)

OTOH, I managed to find out that I can reproduce it with RH7.2 on the
client, but not with RH8.0 on the client (same machine, same server).
It could be something with fonts in menus, because they look different
(on 7.2 they are more "pixelated", and I'm not talking about
Comment 16 2003-04-30 09:24:28 UTC
Yes, stipple performance looks good. 
When the problem depends so heavily on the client (== Xserver side?) and 
the fonts look very pixelated it may be that the old Xserver feature "bitmap 
scaling" is responsible for the problem. Can you change the lines in the 
Xserver configuration file that look like 
> FontPath     "/usr/X11R6/lib/X11/fonts/75dpi" 
and refer to directories with bitmap fonts (e.g. with *.pcf, *bdf , etc. files) to 
> FontPath     "/usr/X11R6/lib/X11/fonts/75dpi:unscaled" 
to prevent "bitmap font scaling"? Is the performance better? 
Comment 17 Unknown 2003-04-30 11:10:04 UTC
My xfs config looks like this:
catalogue = /usr/X11R6/lib/X11/fonts/misc:unscaled,

Furthermore, I did more tests since my last post. The slow performance
is most visible when you click "Tools/Configure", it takes more than 2
minutes for the windows to apear, during which Xserver is jerky,
although it doesn't consume all CPU, only about 25-50%.

But I noticed something else. During this, the machine with Xserver
seems to run xkbcomp several hundred times:
bash-2.05# ps auxww|grep xkbcomp
root      3623  0.0  0.5  2528  656 ?        R    11:54   0:00
/usr/X11R6/lib/X11/xkb/xkbcomp -w 1 -R/usr/X11R6/lib/X11/xkb -xkm -
-em1 The XKEYBOARD keymap compiler (xkbcomp) reports: -emp >  -eml
Errors from xkbcomp are not fatal to the X server compiled/server-0.xkm

So it may be that the error about parsing stdin I posted before is
produced by xkbcomp. But why does it get run so many times and why
does it produce errors? My XFree86.log says "Error loading keymap
/usr/X11R6/lib/X11/xkb/compiled/server-0.xkm", but I don't know why,
the directory is symlinked to local tmpfs.

So, what now?
Comment 18 fa 2003-05-01 08:39:36 UTC

Just a quick note.  We had sub-par menu dropping performance on the Mac OS X
port a while back, and it WAS related to keyboard input stuff.  We even had errors
exactly like this.  The problem with menu speed was that this logging of errors
happens _every_ menu item, and significantly slows down the drawing.

The solution?
revision of vcl/unx/source/app/keysymnames.cxx
			XkbDescPtr pXkbDesc = NULL;
			// try X keyboard extension
             #ifdef MACOSX
               // FIXME
			// XDarwin doesn't yet have very good support for the Xkeyboard 
			// When we call XkbGetKeyboard(), the XServer throws a message up 
in the
			// console about xkbcomp and files for geometry include.  The side 
effect of
			// this is _very_ noticable lag when drawing menus.  The file menu, 
for example,
			// takes about 1s to come down on my G4/450 DP and you can see it 
draw.  Therefore
			// we are disabling it for the moment until better XDarwin support 
			// It is so ordered.
               if ( 0 )
			if( pXkbDesc = XkbGetKeyboard( GetDisplay(), 
XkbAllComponentsMask, XkbUseCoreKbd ) )

So its related to your keyboard stuff most likely.  Hope this helps.

Comment 19 2003-05-06 09:27:30 UTC
HDU->PL: See above, the slow performance seems to be caused when we 
access the keyboard. I don't know enough about this access to analyze the 
Comment 20 philipp.lohmann 2003-05-06 10:17:34 UTC
i don't know what causes xkbcomp to fail in your case; i have to
assume that your keyboard description contains an error. Without a
method of reproducing the problem i cannot say anything more.
Comment 21 pichi 2003-07-21 13:14:40 UTC
I'm sure, it's caused by xkbcomp. I was tryed this way:
1/ Logg in failsafe session in gdm (only xterm) at X terminal to
2/ Start OOo
3/ It's work fine, stop it.
4/ Set up keyboard by xkbcomp, may be: setxkbmap "us" -print | xkbcomp
5/ Start OOo
6/ It's cripled. 

It's may be caused only when keyboard have some buggy configuration
(some warnings at point 4/; in my case RH9 with LTSP 3.0.9).
It's tested with OOo 1.1RC
Comment 22 pichi 2003-07-21 14:29:02 UTC
I think it's very often with Xterminals and also with remote run. In
this cases often Xserver is different version as Xclients as setxkbmap
and xkbcomp (What may produce some incompatibility). I don't
understant what interference between OOo GUI and keyboard set, when
other application haven't. It's big problem for nonenglish users who
must switch keyboard and who can't use xmodmap.
Comment 23 philipp.lohmann 2003-07-21 15:08:36 UTC
OOo tries to get the real keyboard name (that is e.g. "Ctrl" on an
english keyboard, "Strg" on a german one) for a key, so it can print
them as the accelarator key in a menu. The XKB extension is used to
achieve this. If the keyboard configuration is broken it should be fixed.
Comment 24 pichi 2003-07-23 16:53:37 UTC
OK. I understand. Now I fixed this by XF86 4.3 from Slackware. It's
not boring to implement to LTSP but to future will be better if OOo
GUI load this accels one time, not every menu rooldown. I think,
actualy implementation is so stupid.
Comment 25 philipp.lohmann 2003-07-23 17:00:22 UTC
Actually it does that only once if it gets an answer at all (you can
see the code in gsl/vcl/unx/source/app/keysymnames.cxx lines 603-646.
What i could do would be to actually take no for an answer and let it
fail only onec; your're right, the code is a little stupid in that regard.
Comment 26 philipp.lohmann 2003-07-24 17:16:17 UTC
done in CWS vcl7pp1rc
Comment 27 philipp.lohmann 2003-08-04 11:38:50 UTC
verified in CWS vcl7pp1r1
Comment 28 philipp.lohmann 2004-01-27 10:26:20 UTC
merged long since
Comment 29 edsuom 2004-06-29 04:11:33 UTC
This is still a major, show-stopper problem with OOo 1.1.1.

Platform: Gentoo 2.4.24 kernel, LTSP 4.0 thin client configuration