Apache OpenOffice (AOO) Bugzilla – Issue 6044
General GUI performance very slow, especially on remote X server
Last modified: 2004-06-29 04:11:33 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).
changing component and QA contact to gsl: if at all, this is a problem of the graphics system layer.
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).
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, Mathematica... Network is switched full duplex 100. Only five machines in testing environment. 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 better.
Created attachment 4288 [details] xdpyinfo output for machine which is very slow
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
Linux staff.
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.
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 /var/log/XFree.0.log)?
Additionally it would be interesting to know where the scalable font files are. Are they on a network filesystem?
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.
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 4.2.99.2. 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 slowness. 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
> I have OO 1.0.1 but am downloading 1.0.2 and will try it out. I'm very interested in the results.
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). Hints?
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?
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 from smith.cb.ac.at 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 antialiasing).
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?
My xfs config looks like this: catalogue = /usr/X11R6/lib/X11/fonts/misc:unscaled, /usr/X11R6/lib/X11/fonts/75dpi:unscaled, /usr/X11R6/lib/X11/fonts/misc, /usr/X11R6/lib/X11/fonts/Type1, /usr/X11R6/lib/X11/fonts/Speedo, /usr/X11R6/lib/X11/fonts/cyrillic, /usr/X11R6/lib/X11/fonts/CID, /usr/X11R6/lib/X11/fonts/local, /usr/X11R6/lib/X11/fonts/latin2/Type1, /usr/share/fonts/default/TrueType, /usr/share/fonts/default/Type1, /usr/share/fonts/ja/TrueType, /usr/share/abisource/fonts, /usr/share/AbiSuite/fonts 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?
Hi, 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 1.6.8.1 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 extension. // 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 exists. // It is so ordered. if ( 0 ) #else if( pXkbDesc = XkbGetKeyboard( GetDisplay(), XkbAllComponentsMask, XkbUseCoreKbd ) ) #endif --------------------------------------------------------- So its related to your keyboard stuff most likely. Hope this helps. Dan
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 problem.
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.
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 Appserver. 2/ Start OOo 3/ It's work fine, stop it. 4/ Set up keyboard by xkbcomp, may be: setxkbmap "us" -print | xkbcomp - $DISPLAY 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
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.
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.
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.
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.
done in CWS vcl7pp1rc
verified in CWS vcl7pp1r1
merged long since
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