Issue 105116 - Opening odp file freezes Office (allshapes.odp)
Summary: Opening odp file freezes Office (allshapes.odp)
Alias: None
Product: Impress
Classification: Application
Component: ui (show other issues)
Version: DEV300m58
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: oooqa, performance
Depends on:
Reported: 2009-09-16 10:01 UTC by wolframgarten
Modified: 2017-05-20 11:08 UTC (History)
6 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

bugdoc (37.18 KB, application/vnd.oasis.opendocument.presentation)
2009-09-16 10:02 UTC, wolframgarten
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description wolframgarten 2009-09-16 10:01:42 UTC
Open the attached file: Office freezes while generating slide pane previews.
Works in 3.0 final.
Comment 1 wolframgarten 2009-09-16 10:02:48 UTC
Created attachment 64782 [details]
Comment 2 wolframgarten 2009-09-16 10:08:57 UTC
Now I see that the Office does not really freeze but it takes so much tie to
paint the view that it is nearly freezing for the user.
Comment 3 lohmaier 2009-09-26 22:53:20 UTC
also mention allshapes.odp in the description to give people a chance to find it
in a query… 

"nearly freezing" is a euphemism. It blocks with 100% CPU in the range of 5
minutes. The side-pane preview appears a little earlier, but OOo is still not
usable then. And beware of switching to the second slide, then you have to wait
again. Working with such a document is impossible.
Comment 4 lohmaier 2009-09-26 22:54:09 UTC
*** Issue 89775 has been marked as a duplicate of this issue. ***
Comment 5 clippka 2009-09-28 13:11:05 UTC
cl->af: I can reproduce under xp, loading is fast, slide is painted instantly
but slide sorter preview generation takes a complete core. please decide if this
is armin or you
Comment 6 clippka 2009-09-28 15:32:38 UTC
cl->aw: looks like most of the (infinite) time is spend in
SdrObject::RecalcBoundRect() so maybe on for you :-)
Comment 7 Armin Le Grand 2009-09-29 13:37:18 UTC
AW: Hmmm, very strange. Checked in my CWS aw078 and it just takes seconds to
create the views. OTOH in the original DEV300 m57, it indeed takes ages. It's
fixed with something i did in that CWS, but i cannot guess instantly what it
might have been. Need to investigate...
Comment 8 Armin Le Grand 2009-09-29 13:46:01 UTC
AW: Definitely caused by the complex 3D shape on 2nd page. When removing it (or
converting to bitmap) all works well. As said: WIth my CWS aw078 i do not need
to removeit, i get comparable speed as if removed. Maybe the 3D HitTest whci i
massively speeded up in that CWS...
Comment 9 Armin Le Grand 2009-09-29 14:12:19 UTC
AW: Took a closer look at the 3D object. It's a rotation object constructed of a
PolyLine (break it open in draw) with 194 points, divided into multiple shapes,
none of them closed and all with a LineWidth of 0,5 cm and 85% transparency.
This indeed WILL expand to a VERY expensive 3D geometry; each fat line is
extended to 2D geometry and then rotated; all that painted in transparency mode
in 3D. I can not reproduce how that shape may have been constructed; as said,
the partial polygons are not closed, but look as if they should be.  The lines
have an unknown type of LineEnds, too (circles?), which seem to be defined as
beziers and also have a radius of 0.5. All that creates a massive 3D geometry
and there is no way to change that. The only way to get such a monster of 3D
geometry painted faster is a HW-accelerated 3D renderer. Even that renderer
would need the geometry construction, which will be a good part of the time used.
Also helpful will be to parallelize the 3D software renderer, but the best thing
would be not to define such geometries. Extremely complex geometries like this
one WILL get slow whatever system running on or whatever rendering hardware will
be used.
AW: Also checked with DEV300 m29 (last version without primitives): The 3.0 is
also pretty slow with this, but faster. I guess the difference is that 3D is now
AAed, too.
Comment 10 Mechtilde 2009-10-03 17:57:23 UTC
I can reproduce it with several presentations

So I propos this is a stopper for the beta version

At this time testing the impress modul is impossible
Comment 11 clippka 2009-10-03 21:05:27 UTC
cl->mechthilde: maybe you confuse this issue with the other one which is about a
total freeze in m60 as soon as the presentation document has more than one
master pages? this is already addressed for 3.2 beta in cws impressnotes03.
which is integrated and should be in the next build. this issue is only about a
3d shape performance
Comment 12 Mechtilde 2009-10-04 08:40:06 UTC
sorry I didn't look for
and this also happen if you use a presentation with one master page
Comment 13 Armin Le Grand 2009-10-05 10:31:28 UTC
AW: This is no crash and no loop. It's just an object which needs some time to
get rendered. This is a constructed case by adding an extremely complex 3D
object on page2 (You may construct the same case with any kind of object my
making it complex or multiplying it). It's not a case which occurs in practice.
Tipp: Convert complex objects (You already notice when constructing them) to
Bitmaps for use in presentations).

It's also slow in 3.0 and 3.1, it got (of course) slower with using AntiAliasing
(higher quality) for 3D with 3.1 (no regression, that's the unavoidable price
for AntiAliasing; You may switch AA off).

I See no reason for a stopper. I do not even see a reason for Prio2. We know
that we would neeed asynchronious paint, and that faster painting is always
welcome, but it's no regression.
Comment 14 uwe.luebbers 2009-10-05 11:37:37 UTC
Removed keyword "regression", because it did not fit, beside that I do not see
where the
issue is. Maybe somebody can find out if it is slower with AA turned off then
older versions.
In this case I will accept this issue as prio 3-4 performance.
Comment 15 Armin Le Grand 2009-10-06 16:50:34 UTC
AW: Changing target and Issue type, also adding keyword 'performance'.
Comment 16 Armin Le Grand 2010-01-06 15:46:43 UTC
AW: Changed priority
Comment 17 Armin Le Grand 2010-06-08 10:24:33 UTC
AW: Adapted target
Comment 18 cno 2010-06-08 21:09:35 UTC
see issue 112228
Comment 19 Armin Le Grand 2010-06-09 10:20:11 UTC
AW->cornouws: #i112228# would not do anything here; it's a 3D scene which gets
rendered with the internal renderer; instead #i112090# helps here and #i104002#
would, too.
Comment 20 groucho266 2011-01-31 15:30:01 UTC
I just had a look at this document (to test another issue).  I found that a
large part of this problem is the huge number of shadow primitives.  About
110000 2D polygon primitives are created for the monochrome shape area.  It
takes a lot of time just to delete this number of primitives when I switch to
another slide.

With this many polygons to render, antialiasing may add its share to the time it
takes to render the slide.

I am not sure how this can be fixed, though.  Joining all shadow polygons with
our current O(n^2) algorithm would make the problem worse.  Even an optimized
O(n log n) algorithm may not improve the overall time to create the primitives
for the shadow.
Better and easier to implement might be to create one primitive with 110000
polygons instead of 110000 primitives with one polygon each, both with respect
to memory consumption and to render time.
Comment 21 Marcus 2017-05-20 11:08:45 UTC
Reset assigne to the default "".