Issue 105769 - Bezier curves are very slow in OOO320m1
Summary: Bezier curves are very slow in OOO320m1
Alias: None
Product: Draw
Classification: Application
Component: editing (show other issues)
Version: OOO320m1
Hardware: All Unix, all
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: wolframgarten
QA Contact: issues@graphics
Depends on: 106127
Blocks: 99999
  Show dependency tree
Reported: 2009-10-09 17:05 UTC by fyva
Modified: 2017-05-20 10:29 UTC (History)
6 users (show)

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

open this file in OOO320m1 and compare with OOO310m19 (or earlier) (17.96 KB, text/plain)
2009-10-12 18:25 UTC, fyva
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description fyva 2009-10-09 17:05:47 UTC
Bezier curves consume a lot of CPU in OOO320m1 and are very slow in comparison
with 3.1.1.
1. Draw a few complicated bezier curves (for example by this extension ).

2. Compare OOO310m19 with OOO320m1. OOO320m1 can't handle what OOO310m19 can
handle. OOO320m1 almost completely hangs.
Comment 1 wolframgarten 2009-10-12 07:59:30 UTC
Please give a detailed step by step description of what you are doing. Drawing,
resizing? Which script of the extension you are using?
Comment 2 fyva 2009-10-12 18:24:02 UTC
1. Open the file (below) in OOO320m1 .
2. Select any shape or click any button.
3. Do the same with OOO310m19.
Comment 3 fyva 2009-10-12 18:25:28 UTC
Created attachment 65324 [details]
open this file in OOO320m1 and compare with OOO310m19 (or earlier)
Comment 4 Regina Henschel 2009-10-12 18:53:46 UTC
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)? 
Comment 5 fyva 2009-10-12 22:31:50 UTC
Yes, I do.
Comment 6 wolframgarten 2009-10-13 11:59:58 UTC
Sorry, with OOO320-m1 I do not have any problems with the given document. How
much RAM does your machine have and which Processor?
Comment 7 fyva 2009-10-13 13:05:48 UTC
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.
Comment 8 wolframgarten 2009-10-13 13:24:10 UTC
Is this an official OOo build you are using or from some other distributor?
Comment 9 fyva 2009-10-13 13:37:45 UTC
All builds are official from official mirrors.
md5: ad907a42dc77af8e1639f1990fb0f171

md5: 1d3573596d80a52932b4cfc3e86d2889
Comment 10 fyva 2009-10-13 15:48:38 UTC
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.
Comment 11 helenrussian 2009-10-16 14:00:21 UTC
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.).
Comment 12 wolframgarten 2009-10-19 08:44:52 UTC
Does it help anything to disable hardware acceleration under tools/options/view?
Do you have any extension installed? Thanks.
Comment 13 fyva 2009-10-19 10:18:12 UTC
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).
Comment 14 fyva 2009-10-19 13:38:27 UTC
If "use anti-aliasing" is unchecked in Options.../OOo-dev/View, then OOo works
very fast. So the issue is with anti-aliasing.
Comment 15 2009-10-19 14:47:54 UTC
@aw: grinding the bugdoc shows that 95% of the time is spent in
  ::basegfx::tools::solveCrossovers( const ::basegfx:B2DPolygon&)
Comment 16 2009-10-19 15:17:24 UTC
@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.
Comment 17 wolframgarten 2009-10-20 11:33:21 UTC
Reassigned. could you have a look at the mentioned stuff from hdu, please? AA
seems to be engaged, too.
Comment 18 Armin Le Grand 2009-10-21 11:05:26 UTC
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).
Comment 19 philipp.lohmann 2009-10-28 11:02:47 UTC
if it's a 3.2 stopper it should have the 3.2 target
Comment 20 2009-11-02 18:24:17 UTC
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 
Comment 21 2009-11-05 14:29:43 UTC
Now good enough for OOO320.
@wg: please verify in CWS ooo32gsl03
testing hint: use an X11 display that supports the xrender extension
Comment 22 wolframgarten 2009-11-10 14:48:13 UTC
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.