Issue 63848 - views.xcu permanently written when dragging stylist
Summary: views.xcu permanently written when dragging stylist
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: 680m161
Hardware: All All
: P3 Trivial with 2 votes (vote)
Target Milestone: OOo 2.4
Assignee: thorsten.martens
QA Contact: issues@framework
: 62256 72019 75745 78902 (view as issue list)
Depends on:
Blocks: 72764
  Show dependency tree
Reported: 2006-03-31 10:57 UTC by Olaf Felka
Modified: 2009-04-04 19:46 UTC (History)
8 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

The declaration of Timer pointer and callback (5.14 KB, patch)
2007-05-09 03:49 UTC, liangweike
no flags Details | Diff
The initialization of Timer within ctor and the implementation of Timer callback function (47.78 KB, patch)
2007-05-09 03:58 UTC, liangweike
no flags Details | Diff
The file contains the modification. (2.42 KB, patch)
2007-05-09 08:14 UTC, liangweike
no flags Details | Diff
diff for all changed files (8.92 KB, patch)
2007-12-28 13:24 UTC, andreschnabel
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Olaf Felka 2006-03-31 10:57:14 UTC
follow up task for 60519:
When dragging stylist or navigator the views.xcu will e permanently written. It
has to be discussed if this is really needed or if it can be handled in a
different way. Keyword: writeback
Comment 1 untel 2006-04-04 05:05:43 UTC
Just to start off: in issue 60519 I mentioned that dragging the Navigator and
Stylist windows in OOo, a file named "Views.xcu_tmp" in the "\Application
Data\OpenOffice.org2\user\registry\data\org\openoffice\Office\" folder is
created, opened, writen and read a many times per second (I noticed that with
Systernals' FileMonitor).
Moreover, while dragging these windows the CPU usage by OOo went to 80% or more,
and I could hear noticably the hard drive being accessed.

Now the redraw problem is easily solved by disabling the "Show window contents
while dragging" option in Windows. In that case though, the "Views.xcu_tmp" is
still being written while dragging, but at least I don't hear that rapid hard
drive access.

Moreover, someone (pl) wrote a fix to solve the redraw problem of issue 60519.
But nevertheless, even with his fix, if I enable the "Show window contents while
dragging" option in Windows the CPU shoots up again to 80% usage or more, with
the accompanying "scrunching" noise of the hard drive.

Of course I see no real use of the "Show window contents while dragging" option,
and I disable it without missing it a bit, and that solves my problem.

But in case the above problem is a symptom of a more serious problem that could
cause future trouble, I think this high CPU usage and hard drive noise is
something to look into.
I want to emphasize here that the "Views.xcu_tmp" file is written many times
whether the "Show... while dragging" is enabled or not, but that only when it is
enabled do the trouble mentionned above appear.

I hope I've been clear enough, and not too long in my description!
Comment 2 carsten.driesner 2006-04-06 16:30:23 UTC
cd: We should think about to change the ViewsOption class in svtools to use the writer 
back feature of the configuration. This should solve the heavy disk use when moving a 
floating window.
Comment 3 Olaf Felka 2006-11-27 11:25:04 UTC
*** Issue 72019 has been marked as a duplicate of this issue. ***
Comment 4 Mathias_Bauer 2006-12-06 17:37:59 UTC
I'm not convinced that this is the solution. IMHO VCL should provide us with a
callback that dragging the window has come to an end. 

I think we should consider fixing this in 2.x time frame; it can be a PITA on
systems where the profile is located on a slow disk.
Comment 5 philipp.lohmann 2006-12-07 10:13:11 UTC
You're too confident in VCL's telepathic abilities then. We cannot know whether
a move event will be followed by another one or not ;-)
Comment 6 Mathias_Bauer 2006-12-07 10:19:55 UTC
The idea is that we ignore all MouseMove events and only react on the
MouseButtonUp following the MouseMoves. Unfortunately IIRC we don't get
MouseButtonUp as it happens on the title bar. But VCL should be able to send a
"FinalMove" event.
Comment 7 philipp.lohmann 2006-12-07 10:48:25 UTC
That would work if there were any MouseMove events involved. But as long as the
stylist and friends are managed system windows, the only message there is is a
ConfigureEvent ("Your window has been moved" courtesy of the window manager).

Besides why this obessive writing of Views.xcu ? What was bad about writing it
when the stylist/navigator window gets closed/hidden ?
Comment 8 Mathias_Bauer 2006-12-07 11:13:00 UTC
In this case you would move the window somewhere, open a new document window and
find the window at the old place. The fix for this issue was writing the
position to configuration when the window gets moved.

So are you sure that it is impossible to get or construct a "final move" event?
I wasn't aware that even VCL does not get any notification about mouse button up
or down events on the caption bar.

In this of course using asynchronous writing would be the only solution. 
Comment 9 philipp.lohmann 2006-12-07 11:32:36 UTC
The title bar belongs to the window manager. On Windows you get events there
(that's why you can e.g. drop files there), but that's only Windows.
Comment 10 Mathias_Bauer 2006-12-07 11:57:38 UTC
Ah, the usual problem that we also had in case of double clicks on the title
bar. Seems that we will need to use the workaround with asynchronous writing of
Comment 11 kpalagin 2007-03-20 03:55:24 UTC
Dear developers,
what is the current status of this issue? 
The problem affects not just Stylist, but Task and Slide panes in Impress, 
Pages pane in Draw, Navigator in Calc (and probably other panes) as well.
Comment 12 Olaf Felka 2007-03-26 13:57:47 UTC
*** Issue 75745 has been marked as a duplicate of this issue. ***
Comment 13 Olaf Felka 2007-03-28 08:41:55 UTC
*** Issue 75745 has been marked as a duplicate of this issue. ***
Comment 14 carsten.driesner 2007-04-25 13:02:19 UTC
cd: Set target to OOo 2.3. We should find a solution for this problem soon.
Comment 15 liangweike 2007-05-09 03:49:57 UTC
Created attachment 44954 [details]
The declaration of Timer pointer and callback
Comment 16 liangweike 2007-05-09 03:58:00 UTC
Created attachment 44955 [details]
The initialization of Timer within ctor and the implementation of Timer callback function
Comment 17 kpalagin 2007-05-09 05:42:14 UTC
thank you very much for your effort!
As far as I know you need to provide code via .diff file and file Join 
Copyright Agreement 

K. Palagin.
Comment 18 liangweike 2007-05-09 06:57:17 UTC
The locations of the two files:
Comment 19 liangweike 2007-05-09 08:14:43 UTC
Created attachment 44961 [details]
The file contains the modification.
Comment 20 carsten.driesner 2007-05-09 08:24:47 UTC
cd->kpalagin: We already have a JCA from liangwike (he is member of the
RedOffice team).

cd: Set Issue Type to "PATCH".
Comment 21 carsten.driesner 2007-05-09 08:29:48 UTC
cd->liangweike: Thanks for your patch. I will add to CWS fwk66.
Comment 22 peter.junge 2007-05-09 09:29:31 UTC
Added block of meta issue.
Comment 23 carsten.driesner 2007-05-09 12:14:09 UTC
cd: Patch checked and accepted.
Comment 24 kpalagin 2007-05-09 14:38:57 UTC
Thank you very much!
Comment 25 carsten.driesner 2007-06-21 09:58:25 UTC
cd->tm: Please verify.
Comment 26 thorsten.martens 2007-06-25 13:21:40 UTC
checked and verified in cws fwk66 -> OK !
Comment 27 kpalagin 2007-12-11 10:23:59 UTC
Apparently the issue is not fixed (in 2.4m239 on WinXP) as dragging "Styles 
and Formatting" causes HDD light to be lit and CPU usage goes to 100%.

Reopening issue.
When testing it is important to make sure "Show window contents while 
dragging" is ON (default on WinXP), because if it is off then neither 
views.xcu is accessed, nor CPU is pegged.
Comment 28 pavel 2007-12-22 20:51:37 UTC
Reset target.

Comment 29 andreschnabel 2007-12-28 13:22:57 UTC
the patch could not work, as it introduces a move timer but does not remove the
superfluous file accesses.

I've changed the patch and applied the same to SfxModelessDialog and
SfxFloatingWindow. So e.g. When moving the Search & Replace window across the
screen, number of file accesses go from ~3000 down to ~200.

When testing the patch, please test moving docked windows (dock within other
docked  windows, dock / undock) esp. on Unix platforms, as this was the piece of
code causing the high number of file accesses.

changed files:

Comment 30 andreschnabel 2007-12-28 13:24:01 UTC
Created attachment 50587 [details]
diff for all changed files
Comment 31 carsten.driesner 2008-01-07 15:12:39 UTC
cd->andreschnabel: Thanks for you patch. I checked it and you are right that we
missed modeless dialogs and resize operations. Fortunately code freeze is just a
week away and I can add your patch to a CWS targeted for OOo 2.4.
Comment 32 carsten.driesner 2008-01-14 07:42:21 UTC
cd->of: Please verify.
Comment 33 Olaf Felka 2008-01-14 08:34:49 UTC
@ tm: Please reverify in fwk82.
Comment 34 Mathias_Bauer 2008-01-16 15:26:32 UTC
verified in CWS by using filemon on WinXP
Comment 35 Mathias_Bauer 2008-01-16 15:27:11 UTC
Comment 36 kpalagin 2008-02-01 06:46:38 UTC
*** Issue 62256 has been marked as a duplicate of this issue. ***
Comment 37 kpalagin 2008-02-21 17:33:34 UTC
*** Issue 78902 has been marked as a duplicate of this issue. ***
Comment 38 andreschnabel 2009-04-04 19:46:19 UTC
closed ok in 2.4 and 3.0 releases