Issue 55112

Summary: regression: OOo 2.0 GUI response is very slow; usability is affected
Product: General Reporter: norbert2 <norbert.notz>
Component: uiAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P4 CC: issues, nesshof, utomo.prawiro
Version: 680m122Keywords: performance, regression, usability
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description norbert2 2005-09-26 19:12:36 UTC
Since OOo version 2.0 the GUI response is very slow. It is so slow that it can
irritate the user in ome cases:

2 example for slow GUI response:

open a writer document
enter a character
press the undo fast many times: The GUI is to slow to disable the undo button
after one undo step.

enter some text
select a part of the text and apply bold style
set the cursor out of the bold fortmatted part while watching the bold button:
it needs some time to change switched-off state

OOo 1.x GUI has no such problem. So its a regression introduced in 2.0.

(All OOo applications seem to be affected.)

(Please change component to framework if necessary; I don't know.)

(I have tested Linux and Windows version.)
Comment 1 norbert2 2005-09-26 19:16:32 UTC
typing error:
"it needs some time to change switched-off state"
"it needs some time to switch from switched-on state to switched-off state"
Comment 2 stefan.baltzer 2005-09-30 16:54:40 UTC
SBA->Norbert2: "some time" is not exactly precise. Please describe the technical details of your 
system as you tell that the behavior is "irritating". 

Please note that the vast majority of users focusses on the bold painted characters IN THE 
DOCUMENT to verify the success of applying that attribute rather than "checking if the attribute 
was applied by looking at the toolbar button's highlight."

In general, I believe that "wasting (processor) time in order to repaint the toolbars" would be at 
the cost of "performance decrease while painting the document itself". And THIS is the most 
important criteria from what I learned by processing several other "UI performance issues"

From what I experience on a Pentium III 500MHz machine with Windows2000, the difference in 
toolbar behavior is NOT any kind of hinderance of "an averages users daily work". Nevertheless, 
I can confirm that in these (Again: not exactly EVERY users EVERY DAY problem) scenarios, 
the correct display of tollbar button highlighting is slower than in OOo 1.1.5.

Note: Beside the toolbar behavior in general, the UNDO functionality was enhanced, too. Now it 
is giving much more information about what actions are (un/re)done. And while "fastly clicking 
undo repeatedly, the contents of these lists is constantly updated.
-> Prio P4, Target OOo Later.

SBA->CD: HB worked on the Undo/Redo enhancements. But the toolbars are your area. 
Please have a look. 
Comment 3 carsten.driesner 2005-10-10 16:29:29 UTC
cd: Accepted. We changed the function which updates the state of UI elements. In
OOo 2.0 we now wait about 200ms for user input, until we start to update our UI
controller. This should minimize the impact of UI updates to the responsiveness
of the applications. May be 200ms is not a good value for all people, but this
is the first request to lower this value.
Comment 4 norbert2 2005-10-22 10:29:16 UTC
"SBA->Norbert2: "some time" is not exactly precise. Please describe the
technical details of your 
system as you tell that the behavior is "irritating"."

norbert2->SBA: I'm using OOo on an Athlon64 3000+ under SuSE Linux 9.3 and - at
work - on a Pentium 4 3000 under WindowsXP.

I think this is not a hardware problem!

I only notice that OOo - since verion 2.0 - feels very indrirect due to this
slow updating. I think you know what I mean ...
Comment 5 norbert2 2005-10-22 10:32:10 UTC
Could someone comment how current MS Office versions behave?
Comment 6 norbert2 2006-05-26 20:31:09 UTC
I have tested MSO 2003. It has fast GUI response. I hope we can get this back
for OOo. Or at least an option...
Comment 7 norbert2 2006-05-26 20:34:09 UTC
There are also other things that update slow now: For example the calculation of
the sum of all selected cells in Calc. I have to wait for the GUI to update when
trying to find the amount of cells to reach a given value.
Comment 8 norbert2 2006-05-26 20:34:59 UTC
(I mean the sum at the bottom/right of the calc window.)
Comment 9 carsten.driesner 2006-06-02 13:24:08 UTC
cd->norbert2: Your last two statements are not related to the update timer, but 
describe a special problem with Calc. Could you please write a second task and 
set component to "Spreadsheet". We shouldn't mix two problems in one task.

cd->cj: Could please add your point of view as representative of the user 
experience team.
Comment 10 norbert2 2006-06-06 20:07:45 UTC
(calc problem is issue 66182)
Comment 11 norbert2 2006-06-06 20:12:16 UTC
heIs ta calc-problem surely another bug? I think that updating the status bar
(this is were the sum is displayed) is also affacted by the GUI update bug.
Comment 12 atdsm 2006-07-10 18:15:06 UTC
*** Issue 66182 has been marked as a duplicate of this issue. ***
Comment 13 atdsm 2006-07-10 18:23:19 UTC
From nn's statement in issue 66182:
"It is the same as issue 55112. The status bar controller is updated using the
normal slot mechanism (slot SID_TABLE_CELL), and the delays are the same as for
toolbox controllers."

As issue 66182 (which deals with the delay in updating the cell sum in Calc)
seems to have the same root cause as this issue it has been marked as a
duplicate of this one.
Comment 14 frank 2006-07-11 10:07:54 UTC
changed target
Comment 15 Mathias_Bauer 2007-12-04 16:20:01 UTC
according to release status meeting -> target 3.x
Comment 16 utomo99 2008-01-04 12:36:04 UTC
add keywords. 

maybe this is related to the java used. 
I hope we can have better performance for the moments, before it is totally 
fixed on version 3. 
at least it is not worst than before maybe ? 


according to

Huge memory leaks in common or easy-to-reach functionality;
e.g. a mail merge operation which leaks 1 MB per merged document
UI responsiveness of a non-essential feature is extremely poor, rendering the 
feature unusable;

but at least this must be p3, instead of p4
Comment 17 Martin Hollmichel 2009-07-28 08:21:46 UTC
may be a duplicate to 8601
Comment 18 Martin Hollmichel 2011-01-13 13:38:20 UTC
I doubt that this issue qualifies for an Prio 2, if performance would be
extremely poor, we would have duplicates or more complains. I agree with SBA to
set Prio to 4 again.
Comment 19 Martin Hollmichel 2011-01-13 13:38:51 UTC
I doubt that this issue qualifies for an Prio 2, if performance would be
extremely poor, we would have duplicates or more complains. I agree with SBA to
set Prio to 4 again.