Issue 96237 - Opening embeddedl form causes massive memory allocation
Summary: Opening embeddedl form causes massive memory allocation
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: open-import (show other issues)
Version: DEV300m35
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: michael.ruess
QA Contact: issues@sw
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2008-11-15 15:07 UTC by drewjensen.inbox
Modified: 2013-08-07 14:43 UTC (History)
4 users (show)

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


Attachments
Screen shot with system sensors for OOo 3 (401.89 KB, image/png)
2008-11-15 15:08 UTC, drewjensen.inbox
no flags Details
Screen shot with system sensors for Dev300_m35 (191.84 KB, image/png)
2008-11-15 15:09 UTC, drewjensen.inbox
no flags Details
3.0 screenshot (113.85 KB, image/png)
2008-11-16 13:57 UTC, r4zoli
no flags Details
m35 graphics slide above text (63.07 KB, text/plain)
2008-11-16 13:58 UTC, r4zoli
no flags Details
separated the text form from the database document (559.80 KB, application/vnd.oasis.opendocument.text)
2008-11-17 10:29 UTC, Frank Schönheit
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description drewjensen.inbox 2008-11-15 15:07:57 UTC
Test machine: AMD 3300+, 1.5 gig RAM
OS: Ubuntu 8.10 (x64)
OO.o: DEV300_m35 (x64)
JRE: SUN 1.6.0_10

To reproduce you need to download the following file:
http://www.ninthavenue.com.au/products/gemstone-ledger/downloads/gemstone-0.4.0.zip

Unzip the file to any location - the file gemstone.odb was a prototype created
with OO.o 2.2

For this test all user applications other then OO.o where closed. Checking
system resources before any OO.o was loaded - CPU 1%, RAM 16%, Swap 3%

Startup OO.o 3.0 (x64), open the ODB file with OO.o 3.0 (x64) and then open the
form "User Manual". The form opens on the screen in ~3 seconds and the system
resources: 
CPU usage never exceeds ~81%
RAM 20%
Swap 3%

Close OO.o 3.0

Startup Dev300_m35, open the ODB file and then the form "User Manual".
The form (when no other applications are active) opens in about 11 seconds and
the system resources:
CPU usage hits ~99% for about half this time
RAM peaks at 98% then fluctuates as the swapping mechanisim kicks in, but
eventually stabilizes at ~96%
Swap: 23%
Comment 1 drewjensen.inbox 2008-11-15 15:08:57 UTC
Created attachment 58016 [details]
Screen shot with system sensors for OOo 3
Comment 2 drewjensen.inbox 2008-11-15 15:09:40 UTC
Created attachment 58017 [details]
Screen shot with system sensors for Dev300_m35
Comment 3 r4zoli 2008-11-16 12:51:01 UTC
Acer Aspire 5102, Turion64 1.8Mhz  2GB RAM
OS: openSuSE 11.0
OOo: DEVm35(x64) 
JRE: SUN 1.6.0_7
Similar results, OOo nearly hangs and scrolling in opened User Manual is very slow. 
Comment 4 drewjensen.inbox 2008-11-16 13:27:27 UTC
Well - can't believe I didn't do this yesterday.

Saved the 'User Manual' form as a stand alone .odt file. Opening in m35 behaves
just as badly as when embedded.

Changing component to Word Processor.
Comment 5 r4zoli 2008-11-16 13:56:17 UTC
Similar on winXP SP3, same Aspire, not so slow as under linux, but similar.
Standalone document I found problems with inserted graphics, attach two
screenshot one with 3.0 no problem, and m35 graphic not in place, slides above text.
Comment 6 r4zoli 2008-11-16 13:57:33 UTC
Created attachment 58027 [details]
3.0 screenshot
Comment 7 r4zoli 2008-11-16 13:58:34 UTC
Created attachment 58028 [details]
m35 graphics slide above text
Comment 8 Frank Schönheit 2008-11-17 10:28:58 UTC
Can reproduce on WinXP.

The problem seems to be in Writer: "Save Copy as..."-ing the offending form to a
separate text document, the problem persists. Also, the document does not
contain any form controls at all.
Comment 9 Frank Schönheit 2008-11-17 10:29:57 UTC
Created attachment 58051 [details]
separated the text form from the database document
Comment 10 Frank Schönheit 2008-11-17 10:34:26 UTC
fs->od: see the attached "Gemstone User Manual.odt" document, which performs
extremely bad in m35 in both opening and scrolling. Also, some of the images
therein are painted at wrong locations and with wrong scales - see page 2, for
example.

fs->aw: cc'ing you. My gut feeling tells me this might be related to your
changes in the drawing layer (I could refrain from using the expression
"primitive changes", which would be way too ambiguous here :) which came in with
m30.
Comment 11 Oliver-Rainer Wittmann 2008-11-17 11:07:17 UTC
Seems to be broken in DEV300m30.
Rendering, Positioning and Performance Ok in DEV300m29. OOo 3.0 is also Ok.

OD->AW: Can you please have first a look on the rendering and the performance,
because I did not see any changes made in DEV300m30 in project Writer, which are
not also included into OOo 3.0? Thx.
Comment 12 Armin Le Grand 2008-11-17 12:36:00 UTC
AW: Looking at the file. Indeed, some of the graphic objects at the left page
column are misaligned and wrongly scaled. Taking a look what kind of object it
is (Drwainglayer or writer graphic object or something else). When deleting that
object(s), all is okay, so the performance has definitely to do with it.
AW: It's a SdrRectObj with tiled bitmap filling. It may be a problem in the
processing of the primitive fill attributes (createNewSdrFillBitmapAttribute).
There, an adaption for GetPrefMapMode is done for the used Bitmap. The bitmap in
question has a PrefMapMode of MAP_100TH_MM, but gets converted using
PixelToLogic, and MAP_TWIP is used for SetPrefMapMode, this is definitely wrong.
Checking if this was done different in pre-primitive versions...

AW: Indeed. Rendering and performance is because of
svx/source/sdr/primitive2d/sdrattributecreator.cxx in
createNewSdrFillBitmapAttribute, line 574: To change, exchange line
			
aBitmap.SetPrefSize(Application::GetDefaultDevice()->PixelToLogic(aBitmap.GetPrefSize(),
aDestinationMapUnit));

with line

aBitmap.SetPrefSize(Application::GetDefaultDevice()->LogicToLogic(aBitmap.GetPrefSize(),
aBitmap.GetPrefMapMode(), aDestinationMapUnit));

This resolves the wrong bitmap scalings and the performance stuff. Also, the
first such object on page one is correctly positioned. Unfortunately, the
objects on the following pages are not. They seem to be anchored to the Header
(???) and are displayed at the next page, not on the one where their anchor is.

AW->OD: Please use above line to fix the performance problem. Unfortunately, You
will have to look for the wrong positioning. HTH.
Comment 13 Oliver-Rainer Wittmann 2008-11-17 12:47:59 UTC
OD->AW:
Thanks for the fast reply and the fast fix for the rendering and performance
problem.
I will take care of the wrong positioning.
Question: Should I check-in your fix or will you take care of this fix?
Comment 14 Armin Le Grand 2008-11-17 14:02:43 UTC
AW->OD: Please check in. I will also add it to my current CWS, but it should
come together with Your evtl. fixes for this issue. It should merge with no big
issues.
Comment 15 Oliver-Rainer Wittmann 2009-01-14 14:08:42 UTC
In the meanwhile the positioning issue has been fixed in cws aw061, issue 97197.

I will check-in the patch from AW in cws sw31bf04.
Comment 16 Oliver-Rainer Wittmann 2009-01-14 14:44:55 UTC
Now, I figured out that AW's patch is already applied in cws aw059, which is
integrated into coming DEV300m39.

Thus, nothing else to do -> FIXED
Comment 17 Oliver-Rainer Wittmann 2009-01-14 14:45:36 UTC
OD->MRU: Please verify solution for rendering/performance issue in DEV300m39 and
solution for positioning issue in DEV300 master, which has cws aw061 integrated.
Thx.
Comment 18 michael.ruess 2009-03-26 12:46:21 UTC
Checked fix in OOO310m7.