Apache OpenOffice (AOO) Bugzilla – Issue 44664
All buttons in toolbars flicker seriously when cursor moved over them.
Last modified: 2005-03-14 09:26:39 UTC
When I moved the mouse cursor over the toolbar, all button under the cursor flickered. I tested OO.o 2.0 beta under Linux, and these flickering GTK+-styled toolbar buttons have deep impact on user experience. This problem is quite annoying and didn't exist in OO.o 1.x. Thank you.
SBA: Component changed to "Framework". Reassigned to TM.
cd->pl: Looks like a GTK-plugin problem. Can you please have a look.
I cannot reproduce that problem. Could you tell us a bit more about your environment ? Are you using a special Gnome theme ? What kind of machine are we talking about ? Are you displaying OOo on a remote display ?
Environment: Linux distro: Debian Sarge (testing) XWindow: X.org (from Ubuntu) Desktop: KDE 3.3 GTK+ 2.0 theme: Industrial (I've installed gtk2-qt-engine, but all of other GTK+ programs use GTK+ theme normally) Locale: zh_TW.Big5 What additional information do you need? I can post them to help you debug the great office suite. Thanks a lot!
I execute OO.o 2.0 beta on local display 0. My machine is an IBM compatible x86 PC.
The flickering might be due to the fact that the new native widget rendering (NWF) that makes OOo look like other gtk applications is more costly than the traditional method which results in slower painting. This could be especially noticeable on slower machines. If you set the environment variable SAL_USE_VCLPLUGIN to "gen" in a shell and execute OOo from that shell, does the flickering vanish ? This should give you the old method for painting toolbars.
After set SAL_USE_VCLPLUGIN=gen, OpenOffice.org 2.0 beta works normally. Old method paints the buttons very fast. Apparently the new drawing method should be heavily optimized. I'm sure that it's not running on a slower machine. If a PC with a 1.6 G CPU and a 64MB Nvidia card is too slow to run OO.o 2.0, this only means the software is slower, not the hardware. Even my old machine Pentium II 266 MHz machine bought 7 years ago can run M$ Office 2000 smoothly. So if OO.o 2.0 is released with this defect unfixed, I think it will make all OO.o advocates unable to introduce this great software to others. Thank all of the developers for this great fre software.
No, a 1.6 GHz machine would run the gtk styled toolbars normally, in fact it does so on my very desktop. So the problem lies somewhere else. What exactly do you mean by flickering ? I guess you do not mean that each button is highlighted if you move the mouse over it ? Because this was also done in 1.1, only not gtk styled.
When I move the cursor over a button, it will be highlighted with a raised border. But it seems that the background of that button is completely cleared first, and the icon displayed on the button is wiped out. Then, the icon is painted on the cleared background again after the button has been given a raised border. Besides, when I've moved the cursor to hilight another button, the original highlighted button still has the raised border at that moment, and then the border disappears. This is what I mean. All of the redrawing when a button is highlighted needs to be done in several milliseconds and shouldn't be noticed by the users. OO.o 1.x doesn't has this problem, the button is highlighted smoothly. But OO.o 2.0 beta draws the hilighted buttons with flickering. Maybe you guys should consider double buffering. Seeing the drawing process step by step when OO.o 2.0 highlighting the buttons is not a pleasant experience. Double buffering can solved the problem, but the drawing speed still needs optimization. There must be a bug in GTK+-style related code. Redrawing a button shouldn't be such a time consuming task. I don't know why you didn't encounter this, but I see this problem everytime when I move my mouse over the toolbars. Hope you can fix that for this great office suite.
I did some further testing. Under GNOME or XFCE, the most famous GTK+-based desktop environments, OO.o 2.0 doesn't have this toolbar-related problem. But I encounter this problem under KDE 3.3 with gtk2-engines-gtk-qt installed. The distro I use is Debian testing. It seems that only when OO.o 2 runs under KDE can this problem be reproduced. There is no problem under GNOME except some crash without known cause.
Ye, the gtk <-> qt mapping is qute costly. For that reason we will not use gtk on KDE anymore. This is fixed with issue 41806 which has yet to reach the master build *** This issue has been marked as a duplicate of 41806 ***
closing duplicate