Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||views.xcu permanently written when dragging stylist|
|Product:||General||Reporter:||Olaf Felka <olaf-openoffice>|
|Status:||CLOSED FIXED||QA Contact:||issues@framework <issues>|
|Priority:||P3||CC:||ace_dent, andre.schnabel, atlanx, issues, kpalagin, Mathias_Bauer, philipp.lohmann, takeda|
|Target Milestone:||OOo 2.4|
|Issue Type:||PATCH||Latest Confirmation in:||---|
|Issue Depends on:|
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 ViewOptions.
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
liangweike, 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 (http://website.openoffice.org/files/documents/28/1006/contributing.html). WBR, K. Palagin.
Comment 18 liangweike 2007-05-09 06:57:17 UTC
The locations of the two files: sfx2/inc/dockwin.hxx sfx2/source/dialog/dockwin.cxx
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
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: framework/sfx2/inc/sfx2/basedlgs.hxx framework/sfx2/source/dialog/basedlgs.cxx framework/sfx2/source/dialog/dockwin.cxx
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