Apache OpenOffice (AOO) Bugzilla – Issue 60519
Abnormal Behavior with Navigator and Styles Windows
Last modified: 2006-07-03 10:13:08 UTC
The "Styles and Formating" window (through "F11" key or menu) and the "Navigator" window display an abnormal behavior on my OOo 2.0.1 on Windows2000 SP4, with latest Java (1.5.0_06-b05): In Writer or Calc, in an empty document: Dragging the "Styles and Formating" window leaves behind it a succession of image were it has passed, thus showing a multitude of 'ghost windows' images as an ongoing trail; only when the dragging is stopped (or releasing the window) does this sequence of overlapping window images disappear, the client window having decided to redraw itself I guess. Moreover, during this dragging of the "Styles and Formating" window, the CPU is using around 80% or more, continuously, augmenting along with the speed of the dragging. And along with this, there is noticeable activity on the hard drive while dragging the window, there is reading/writing activity going on, which stops when the dragging stops. This doesn't happen on OOo 2.0.
Created attachment 33216 [details] trail of overlapping Navigator window images
Hi, this is a duplicate, so the problem is already known; but I can't find the duplicate number atm.
closing
can't find issue to which this is duplicate, so reopening; observation from reporter: with systernal's FileMonitor (http://www.sysinternals.com/Utilities/ Filemon.html), I've seen that OOo creates, opens, writes and reads a tremendous amount of times a file named: "Views.xcu_tmp" in the "\Application Data\OpenOffice.org2\user\registry\data\org\openoffice\Office\" folder, I guess for writing where the Navigator window is moved as I drag it. This is the cause for the hdd access which in turn leads to jerky redraw of the navigator or stylist when moving it.
confirmed with OOo 2.0.2 RC1 on WinXP Pro SP2
I've seen this too. I would like to add that on my system (windows 2000) trying to drag the window usually freezes OO and I have to kill it and reboot. There is something wrong with the whole. I've found this both in Writer and in Master Document. The freezing behavior is so severe it makes OO pretty much useless on my system. If this freezing/crashing is related I'd elevate this issue to VERY high priority. I alos may submit a separate issue for the freezing issue I've been seeing -- though it may be related to this.
Problem subsists in final 2.0.2 build (Windows 2000 sp4). Also, the "Views.xcu_tmp" file activity occurs even when the Navigator or Styles windows are docked (anchored) on the side while the width of the window is modified.
The graphical anomaly exists even with OOo 2.0.2 for Linux, on Mandriva Linux 2006. So this isn't limited to Windows platform. BUT the frequent hard drive reading/writing activity *doesn't* seem to be present though on the Linux platform (i would have to get a tool similar to FileMonitor for Linux to be certain).
The following acceptable (and quite simple!) solution has been given by a OOoForum user (BMarcelly): Simply disabling the "Show window contents while dragging" option prevents the badly redrawing of the Navigator and Styles windows. In Windows 2000 this is done through the "Display Properties" control panel: Control Panel>Display Properties>Effects tab, uncheck "Show window contents while dragging". In Windows XP: Control panel>System>Advanced>Performances>Visual Effects, and uncheck "Show window contents while dragging". It seems (in my win2000 system) that the frequent hard drive reading/writing activity is also solved this way. Another user indicated a similar solution in Linux. So fixing this problem isn't much as important as I thought, P4 or P5, but I don't know how to change the priority here.
Additional information: On WindowsXP I've switched to 'Display window content while dragging in the Display properties'. The you can the effect that the repaint is kind of weird. As long as you drag the windows it doesn't repaint the background. Stopping dragging and the painting is ok. I don't know if the cause is the same: Doing this on Windows Vista and Office freezes.
Actually it also freezes on my Windows 2000 SP4, I actually reported it in issue 62256
*** Issue 62256 has been marked as a duplicate of this issue. ***
There is another related issue, that the workaround doesn't solve. The freeze _sometimes_ occur when you for example use formula editor in the writer and you're switching between formula editor and the writer. I also remember that it happened, when I used calc inside in writer.
I can fix the trailing windows issue (which is a windows problem where windows itself will not elapse timers during the move). Fixed in CWS vcl56 If Views.xcu is written too often, that is a framework issue and should be addressed in another issue. Any Vista specialties are another issue also and should accordingly be handled in other issues.
pl->of: if you can confirm that the Views.xcu is written all the time during moving a window, then please write an issue to framework and assign it to cd.
I actually reported the bug in different area, but somebody said is a dupe. I think all of those issues are related. And I bet that once the source of problem is fixed all of them will be fixed. You said you fixed the trailing windows problem, in CWS vcl56. Is there a binary version (for windows) o that branch so I could download it and test if the problem still presist, and eventually open new bug (since as you said it should be reported separately)
The continual accessing of Views.xcu can only be framework; Views.xcu is used to store persistent window positions (so a dialog or the stylist or navigator will show up in the same place as before e.g. on next start). If that is consistently written to during moving the framework would have to fix that. The trailing windows problem was due to the fact that OOo collects paint events over a timer and only paints this collection after a timer has elapsed; the problem was that Windows itself will dispatch timer messages with the lowest priority of all events, so the timer never elapsed before the move basically ended; this is what i changed. I can attach a binary version of the vcl680mi.dll (containing the fix) to this issue; this would be binary compatible to be put under a 680m160 version.
Created attachment 35224 [details] zipped vcl dll containing the fix (compatible to 680m160 build)
please verify in CWS vcl56 re-open issue and reassign to of@openoffice.org
reassign to of@openoffice.org
reset resolution to FIXED
of: For the permanently writing of temporary view.xcu I have to discus with developer if we can handle it different. For the freeze on Vista I've filed issue 63842 to have a look. This issue is fixed in cws vcl56.
of: For 'views.xcu problem' I've created issue 63848. It has to be discussed if changes are possible.
Folluw up issue for linux: 63853
@pl concerning the vcl680mi.dll fix for 680m160: I installed OOo 680m60, then overwrote the above vcl680mi.dll in the program folder. The Navigator and Style windows now redraw better now, even with the "Show window contents while dragging" enabled. I just want to note here however that draging the windows still takes a lot of cpu power, much more than in child windows of other apps. Perhaps this is due to the Views.xcu_tmp writing, I don't know. I'll write about it in the 63848 issue. Also, there seems to be a bug with your fix: when I go to the General Options, doing Tools->Options->General, OOo crashes, closes suddenly. It doesn't do that with the original vcl680mi.dll.
That crash is fixed already, i just didn't attach a new library to conserve space. Thank you for noticing.
*** Issue 60338 has been marked as a duplicate of this issue. ***
Lokks better in m167.
Isn't fixed after all. CPU used to nearly 90% while dragging. I'll just revert to the usual solution of unchecking "Show window contents while dragging" in the Effect tab in the "Display Properties" control panel. Just wanted you to know this was still there. With the preceding solution, there's no hurry.
Tested with OOo 2.0.3 680m173 b9040. Defect persists: Still seeing multiple trails when dragging window. However, the remaining problem might be due to Issue 63848 ? Regards, Andrew
Oops! Had forgotten about that follow up. Thanks for the reminder. Sorry. Please re-close.
Reclosing
.