Issue 105769

Please give a detailed step by step description of what you are doing. Drawing,
resizing? Which script of the extension you are using?

1. Open the file (below) in OOO320m1 .
2. Select any shape or click any button.
3. Do the same with OOO310m19.

Created attachment 65324 [details]
open this file in OOO320m1 and compare with OOO310m19 (or earlier)

In DEV300m61 on WinXP is no performance difference. I can work with the curves
without problems: moving, rotating, editing points, formatting.

Do you use an original OOo-version (see Help > About)? 

Yes, I do.

Sorry, with OOO320-m1 I do not have any problems with the given document. How
much RAM does your machine have and which Processor?

1,6 GHz Celeron, 2GB RAM (Ubuntu 8.04)
Not that it hangs forever, it waits for about 20 seconds for any action. I can
rotate and move curves, but it takes for about 20 seconds for each action. With
OOO310m19 it takes about 2 seconds against 20 seconds with OOO320m1 - about 10
times difference in speed.

Is this an official OOo build you are using or from some other distributor?

All builds are official from official mirrors.
OOo-Dev_OOO320_m1_LinuxIntel_install_en-US_deb.tar.gz
md5: ad907a42dc77af8e1639f1990fb0f171

OOo_3.1.1_LinuxIntel_install_ru_deb.tar.gz
md5: 1d3573596d80a52932b4cfc3e86d2889

Can this issue be connected with the video driver (videocard Intel GMA 900)? I
just checked DEV300m61 - the same behavior as OOO320m1. Watch a video of what I
see on my screen when the attached file is opened with OOO320m1.
http://www.youtube.com/watch?v=v3ZnQytLQ2A

I confirm this problem on Linux OpenSUSE 10.3.

With OOo dev300m60, OOo320m1 file opens very slow (5 min. or longer).
With OOo 2.4.3 - normal (5-7 sec.).

Does it help anything to disable hardware acceleration under tools/options/view?
Do you have any extension installed? Thanks.

Deleting profile or turning off all extensions do not help. The checkbox in
Options/.../View is unchecked and greyed out (Ubuntu 9.04 on VirtualBox).

If "use anti-aliasing" is unchecked in Options.../OOo-dev/View, then OOo works
very fast. So the issue is with anti-aliasing.

@aw: grinding the bugdoc shows that 95% of the time is spent in
  ::basegfx::tools::solveCrossovers( const ::basegfx:B2DPolygon&)

@aw: a deeper look into the grind result shows that half of these 95% is spent in findEdgeCutsOneBezier() 
which seems to test a bezier curve for self-intersections. It does this by subdividing it into 50 linear 
segments. Maybe that approach could be replaced by using my B2DCubicBezier::getExtremumPosition to 
identify and split non-trivial bezier segments.

Reassigned. could you have a look at the mentioned stuff from hdu, please? AA
seems to be engaged, too.

AW: After long discussion HDU will take over for now. Basic problem is that the
intersection solvers in basegfx are expensive (potentially need to change
polygon topology) and should not be used during paint. Instead it would be
optimal to extend the trapezoid generator to solve that problem locally (short:
to work with crossovers).

if it's a 3.2 stopper it should have the 3.2 target

Fixed in CWS ooo32gsl03: Avoiding solveCrossovers() by using an own intersection solver the performance 
is increased dramatically (for the testcase the factor is about 80x).

In another CWS I'll move the new solver into basegfx and extend it for handling beziers directly. This 
should give it another significant performance boost as the number segment-pairs to be tested for 
intersection will be much lower than when all the line-segments after bezier-subdivision have to be 
tested.

Now good enough for OOO320.
@wg: please verify in CWS ooo32gsl03
testing hint: use an X11 display that supports the xrender extension

Much better now as in OOO320_m3 but not as good as in 3.0 final. So much we can
do for now. More will follow. Verified.