To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=107869
                 Issue #|107869
                 Summary|Dynamically load/unload graphics objects to minimize m
                        |emory footprint
               Component|Word processor
                 Version|DEV300m67
                Platform|All
                     URL|
              OS/Version|All
                  Status|UNCONFIRMED
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|ENHANCEMENT
                Priority|P3
            Subcomponent|open-import
             Assigned to|writerneedsconfirm
             Reported by|punisher





------- Additional comments from punis...@openoffice.org Thu Dec 24 07:43:16 
+0000 2009 -------
_THE ISSUE_

The way OO Writer currently handles graphics objects, in documents, is to load
every single graphic and keep it in memory for the entire duration for which the
document is open.  The impact of this approach is the subject of Issue 102773.

In the case of the aforementioned issue, an 82-page, 11.4 MB .odt document,
containing many graphics objects, is initially opened very quickly (about 3
seconds) and memory usage increase is marginal; but about a second later, Writer
proceeds to load every single graphic in the file, tying up the processor for
over a minute and bringing total memory consumption beyond 417 MB.  I'm on a P3
system.  By comparison, the same document, converted to .doc format and opened
in MS Word, is opened quickly and with much less than 100 MB (began under 40 MB
and peaked around 60 MB when the document was scrolled up and down).  This isn't
a format issue, because when the same .doc version is opened with OO Writer,
over 400 MB of memory is again consumed.  Note: the aforementioned timings do
not include application start times.  In both cases, the applications were first
started then the documents were drag-dropped.

Now imagine if someone was attempting to use OO Writer to produce a 400-page
guide containing many screenshots.  What would OO Writer require then?  I'm
assuming as much as 3 GB.  This is unreasonable.


_REQUESTED SOLUTION_

In my experience, MS Word does not keep all graphics loaded all the time
(correct me if I'm wrong), and I do not see why OO Writer cannot do something
similar.  My request therefore, is that OO Writer take an approach somewhat like
the following (I'm sure there are better approaches; these are just my 
thoughts):

1. Load all graphics objects for the page in view, obviously;
2. Load all graphics objects for the 10 pages before (if any) and 10 pages after
(if any) the current view;
3. If the cursor is out of view (not on the current page) and is outside the
bounds of the pages in #2, speculatively load graphics objects for the 5 pages
before (if any) and 5 pages after (if any) the page currently with the cursor;
4. If #3 was true and the cursor is then brought into the page in view (e.g. by
clicking the viewed page), short delay unload the graphics objects in #3;
5. If #2 was true then, upon scrolling such that a page is outside the bounds,
lazy unload the graphics objects for the page now out of bounds and immediately
load the graphics objects for the new page(s) in bounds (if any); and
6. An additional factor, such as a memory bounds parameter, could facilitate the
loading of graphics objects from even more pages, so long as the memory bound is
not exceeded.

The above selection of 5 and 10 pages is just for discussion.  Whatever is
optimal would be best and would depend both on OO load/unload performance and
user perception.

All that being said, I can't code or understand code for anything as complex as
OO, so it's entirely up to the OO devs whether my request is even considered.

Thanks

---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org
For additional commands, e-mail: issues-h...@sw.openoffice.org


---------------------------------------------------------------------
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org

Reply via email to