Issue 105116

Created attachment 64782 [details]
bugdoc

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.

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.

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

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

cl->aw: looks like most of the (infinite) time is spend in
SdrObject::RecalcBoundRect() so maybe on for you :-)

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...

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...

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.

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

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

sorry I didn't look for http://www.openoffice.org/issues/show_bug.cgi?id=105382
and this also happen if you use a presentation with one master page

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.

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.

AW: Changing target and Issue type, also adding keyword 'performance'.

AW: Changed priority

AW: Adapted target

see issue 112228

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.

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.

Reset assigne to the default "issues@openoffice.apache.org".