Issue 102380

nexonic,
is there a way you can provide the file?

I couldn't find a hoster that allows such a big file so I had to upload it on my
homeserver:
http://drop.nc.homeunix.com/file.php?f=impress_test_file.odp

Unfortunately I can't keep the server running everytime.

Confirming with 3.1 on WinXP. Repro:
1. Open linked .odp.
2. In Task pane click "Slide Transitions", Advance Slide - Automatically after 
1sec, then click Apply to all slides.
3. Press F5, wait for Impress to attempt showing fisrt several slides and 
crash.

I can provide .odp if becomes unavailable.

i can reproduce it with files bigger than 500 KB
 examples:http://www.cs.rpi.edu/~drinep/modcomp/class2.ppt 
                  http://www.cs.rpi.edu/~drinep/modcomp/class14.ppt
$ uname -a
Linux myhost 2.6.29-ARCH #1 SMP PREEMPT Wed May 20 06:42:43 UTC 2009 x86_64
Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz GenuineIntel GNU/Linux 1 GB RAM

@2fi: how do you know that this is the same problem? The first file is large and
.odp, your file is rather small and ppt. I do not think that this is the same cause.
Has anyone send a crash report and received an ID for it? I am downloading the
big file right now.

@wg: i have the same problem with large odp and small ppt (large haven't tried).
I never got to the crash part because the computer hangs if i don't kill the
process .
Should i make another bug report for the ppt part?

On windows I get a runtime error after  short time. Reassigned.

I suggest targeting for 3.1.1 as 3.0.0 plays slide show for both 
impress_test_file.odp (huge one) and class2.ppt (small one) just fine.

@2fi: yes, please file another issue and attach one of your files. Thanks.

@kpalagin: I have to shut down my server now. Would be great if you or someone
else could provide the file.

@sun, I copied the bugdoc to so-data/qs/bugdoc/issuezilla/102380

The problem here is that this document needs 1.6 Gig memory, which causes a
swapping on most systems and swapping is a bad thing.

This is a regression to 3.0 since the automatically swap out for graphics does
not work anymore.

I change the target to 3.1.1 since this is a regression and also it is a very
severe one in my opinion. Each pixel graphic does not only need its file size
but its decompressed size in memory...

*** Issue 102627 has been marked as a duplicate of this issue. ***

NOTE: This issue affects odt documents too; thus, this is an application core
issues, as I mentioned in Issue 102627.

I have an 11 MB odt document, containing many graphics, that exhibits this same
problem.  I cannot attach the document due to contractual obligations.

Furthermore, I should point out the inconsistency I observer here in that @2fi
is told by wg to file another bug for his ppt-related issue and yet my Issue
102627 has been duped to this.  Personally, I believe it is all the same bug.

AW->punisher: This cannot influence odt douments in principle; Writer has it's
own implementation of Graphic objects (and it's own buffering/caching
mechanism). We currently work on joining those various objects to a single one,
but it's not the case yet. If You really see the same problem in Writer, please
write a new task for it.

(reply to: aw)
> If You really see the same problem in Writer, please write a new task for it.

Just filed Issue 102773 for the memory leak + crash issue with writer.

AW: Adding to CWS aw074 to take a look...

AW: Okay, here we go. Base of consideration is the SdrGrafObj. GraphicObjects
which are swapped have a swap-pointer set to SdrGrafObj::ImpSwapHdl. When
(view-indeendent) primitives are created (SdrGrafPrimitive2D) from the
ViewContact (VC) inside
ViewContactOfGraphic::createViewIndependentPrimitive2DSequence the GraphicObject
is copied using the copy operator. At this copy, the swap-pointer is not copied.
In principle this is what is wanted; primitives are visualisation objects and
should only exist when the object actually gets visualized; thus it is okay that
the copy is not swapped. To make the swappig work again in principle it is just
necessary to flush the SdrGrafPrimitive2D and it's bufferd decomposition. The
primitives are also buffered at the ViewObjectContact (VOC), but as the name
says this only exists when a view is visualizing the object, so this is
automatically deleted.
That flushing can be done internally using
flushViewIndependentPrimitive2DSequence in the ViewContactOfGraphic
implementation; adding a method ViewContactOfGraphic::flushGraphicObjects() will
do that. A point to trigger this already exists in SdrGrafObj::ImpSwapHdl itself.

After doing this the swapping works as before. I also took a look at the swap-in
time for graphics. There is a mechanism in the ViewObjectContactOfGraphic which
allows asynch loading (using AsynchGraphicLoadingEvent which registers at the
view and is triggered using a timer). This is designed to show a replacement
graphic at first repaint, which at the event rigger, gets replaced and repainted.
That mechanism is currently broken since GraphicObject copy constructor triggers
the SwapIn hard; investigating how to avoid this...

AW: I have now finetuned
ViewContactOfGraphic::createViewIndependentPrimitive2DSequence to use more
cases; it will now locally create content for empty PresObjs
(createVIP2DSForPresObj), for swapped out (createVIP2DSForDraft, new) and for
regular visualisation. createVIP2DSForPresObj needs some finetuning fo robject
text and clipping it when the space (the object size) is not sufficient...

AW: createVIP2DSForDraft finetuning done. Text is now (as in DEV300 m29) taken
from Filename, else from ObjectName and extended by '...'. Graphic is the empty
graphic ressource (as in old versions). Graphic is only used when space is
sufficient. Text is clipped when space is not sufficient. When the GraphicObject
has no LineStyle, a gray outline is added.
Checked with the original bugdoc, works well. Maybe the on-demand load should be
suppressable. Discussing...

AW: Comitting chages up to now to not lose them.

AW: I compared behaviour with the DEV300 m29 (pre-Primitive version). The
difference is in GarphicObjects on the MasterPages; these were also swapped in
that version, but due to the MasterPageCache, it was never missing in the
visualisation. In the new version those garphics get swapped and show the
replacement object from time to time. I have to find a way to solve that (to not
swap those). This is from memory no problem, since the masterpage cache has
normally the same/a even bigger size than the graphic hold in memory. Looking
for possibel solutions...

AW: I made the bDoAsynchronGraphicLoading switch in
ViewObjectContactOfGraphic::createPrimitive2DSequence aditionally dependent from
being an object on a MasterPage. Switching through the pages looks now as
before. Checked in, done.

AW: Ckecked with wntmsci12.pro build, works as expected.

AW->WG: Please reviewas described. The test file is where CL has described.

Verified in CWS.

Tested in m17. Closed.