AW: It's the old tools Polygon which is defined to have UINT16 nPoints. That's
one of the reasons to have basegfx and the new polygons created, besides
numerical problems (integer vs. double precision).

Problem is that this old tools Polygon is so centrally used throughout the
existing codebase that changing it to 32bit PointCount will certainly make hell
break lose. It comes into play with charts e.g. due to Metafile usage. The tools
Polygon is streamed into and read from file-based Metafiles; this means these
need to be adapted, thus backward compatibility will break, too.

Also unknown things (just examples which come to my mind, there will be more):
Does WMF support more than 16Bit point count (if no, we can no longer export to
clipboard). Could all places be found which are based on Tools Polygon's Point
Count? If yes, how many will this be and could they all be adapted at all? Will
VCL be adaptable to it and (more important) are all our systems able to render
such big polygons at all? At least not HW-supported; rendering HW (graphiccards)
have a limited amout of line span entries, so rendering will anyways fallback to
soft renderers (usually with more than 4096 or 8192 points or similar).

All in all: A known problem already worked around (as can be seen: the whole
current DrawingLayer visualisation does not use the tools polygon anymore),
dangerous to touch. The preferred fix would definitely be to reduce point count.
How can a smoothing of a polygon with ca. 4000 points lead to one with 79959
points...?

Also to think about: Is it a defect, or (as it always was this way) is it an
enhancement...?

The resolution for the spline calculation is set to 20, that causes the immense
grow of point count. The reduction of point count on chart side will be
addressed with separate issue 112072. So this one should concentrate on the
rendering engine.
I think it is definitely a defect if API and implementation do not match in
dimensioning.
In long term this should be solved. In short term I can live with workarounding.

AW: This one will concentrate on finding a solution on rendering side, of
course. There are already the basics (new basegfx stuff), but the old office
(and definitions of the forefathers) is in the way (as often) :-( The long run
plan is anyways to get rid of the tools polygon completely.

It is a defect in the sense of the API, when the whole office (unfortunately
containing many old parts) is seen as implementation. It's an enhancement when
knowing that the office comes from never having been able to do such polygons
and gets better step by step.

At least it should not lead to define the UNO API as accepting only polygons
with 65536 points, else throwing exceptions (which would have been a must when
defining the API at the time it was defined :-)).

AW: Just tried: Activating the 2nd chart (the smoothed one) shows that
Drawinglayer is perfectly capable of handling these polygons; so is printing and
PDF exporting (using the ChartPrettyPainter). It's just the transport over the
old Metafile and it's tools Polygons...

AW: The idea of expanding the tools polygon in the Metafile has just died; there
is a VersionCompat written and read when writing the polygon (Polygon::Write and
Polygon::Read), but it is not computed at read time. Thus, all offices out there
are not able to read the polygon in it's evtl. offered old form and could not
read updated Metafiles. ARGH.

AW: Again looked into expanding the tools Polygon to 32bit point count. The
basic change is not too hard (except looking at all places working with a
polygon), but the problem is in the stream and Read/Write operators. There, a
wild mixture of ImplWrite/Write and the stream operators are used. Only
Write(...) uses a version info and could possibly be 'persuaded' to write
polygons with more than 65535 points possibly. Many usages (esp. the Metafile
actions) use the stream operator or even ImpWrite. There are even places where
usages stream the points directly (using NO method for Polygon at all). All this
comes from a endless story of changes/fixes around the tools Polygon and it's
expansions; e.g. the stream operators do not even stream the control point flags (!)

All in all: too dangerous to do. It's better to not touch the Metafile and it's
polygon usages, if avoidable.

But how to avoid? I thought about strategies of point reduction (clipping,
weighted point relevance), but that will lose resolution.

The only way to reduce this problem is to do it where it happens: At the
Metafile creation. In this concrete case, it's a line polygon which could simply
be splitted into many shorter ones. This is also the way to stay backward
compatible. Thus, for lines, split them in halfs. For filled polygons, clip them
hor/vertically when too complex.

Looking where this could be done best...

AW: Nees to be done for SvtGraphicStroke and SvtGraphicFill.

For SvtGraphicStroke it's in PolygonHairlinePrimitive2D,
PolygonStrokePrimitive2D and in PolygonStrokeArrowPrimitive2D. Adding code,
checking...

AW: To test, i limited possible points per polygon to 10. Added code to line
splitting to take open/closed into account. Added code to take curves into
account. Works as expected. Needs to be called recursively; done by creating new
primitives and -re-spawning metafile primitive processor with those.

AW: Let's split fille dpolygons now...

AW: Oops, some changes in VclMetafileProcessor2D will collide with CWS aw082. HG
allows to get aw082 into aw083, doing that...
AW: Went well, no conflicts. On we go...

AW: Line splitting woks well now.
AW: For filled polygon handling i need to take care of five palces:
PolyPolygonBitmapPrimitive2D, PolyPolygonHatchPrimitive2D,
PolyPolygonGradientPrimitive2D and PolyPolygonColorPrimitive2D. Also need to
care in PolyPolygonColorPrimitive2D in the direct handling of
PolyPolygonColorPrimitive2D. Added code which can be used recursively to split
the fill polygon into right/left resp. top/bottom pairs by clipping. Tested with
30 points maximum (due to curves needing already 3 points per edge). Added code
foer curve handling. All cases except the first correct the polygon and directly
create Metafile actions and/or call VCL with that polygon. Only the first case
needs to call the rendere itself recursivey.
AW: PS: Met BM by coincidence yesterday; he told me that he remembers that
exactly this problem was araedy fixed in the old chart module, also splitting
the geometry. I think this is the right place and shold also be changed
there;it's simply also a question of cost when such hge polygons get created.
Nonetheless, it has to work in Metafie stuff (which is VCL, not Drawinglayer).

AW: Re-checking plane splitting...

AW: Okay, works well. Checked in, done.

The difference with the old chart was that it didn't use the UNO API and had no
ways of reducing point count. The new chart has already mechanisms to reduce the
point count. There are only a few cases left, where this is not effective, for
example if signals are very noisy or as it seems with splines -> issue 1120072.

typo: meant issue 112072

AW: Adapted target

AW: Re-checked with wntmsci12.pro build. Works as expected.

AW->WG: Please review.

Verified in CWS.