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"

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. 

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.

"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 ...

Could someone comment how current MS Office versions behave?

I have tested MSO 2003. It has fast GUI response. I hope we can get this back
for OOo. Or at least an option...

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.

(I mean the sum at the bottom/right of the calc window.)

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.

(calc problem is issue 66182)

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.

*** Issue 66182 has been marked as a duplicate of this issue. ***

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.

changed target

according to release status meeting -> target 3.x

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 ? 

Thanks

according to http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#priority

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

may be a duplicate to 8601

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.

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.