BuildPolyLine produces concave curves that are unsuitable for polylines about graphics32 HOT 13 CLOSED

Now I don't recommend it, curiously I took a look in the assembler I noticed that the function generates huge code not suitable for fast tasks

Wow. Yes, that's pretty bad. It copies the dynamic arrays into constant arrays which is then copied back to dynamic arrays.

With regard to community I think people are still "out there" but the community is just completely fragmented; There are too many options. Before there was just the newsgroup. Now there's Github, Delphi-praxis, Facebook, Stackoverflow, etc. - and none of them are as good for discussion as the newsgroups were. Progress :-(
With regard to abandonment I think the activity is pretty normal for a mature library:

from graphics32.

@lamdalili I've applied your change. Looks good:

from graphics32.

@lamdalili FYI

from graphics32.

The example from this comment in #63 demonstrates the same problem:

@AngusJohnson Image32 has the same problem (since it uses the same method to "square" the join).

from graphics32.

I think there is a misunderstanding between offsetting to generate strokes and the standard geometric offsetting. The latter should generate perfect outlines without self-intersections and this was the right to use .

It's important to consider that self-intersections in BuildPolyPolyline are part of its work, and this should be taken into account and generated polygons are filled according to the pfWinding FillMode.

But it's impossible to use polygons returned by BuildPolyPolyline, without cleaning them, to display correctly border

To fix the whole issue, simply create inner and outer circles of the hue band at the beginning instead of using BuildPolyPolyline
by replacing this line

by:

  HueBand := [Circle(FCenter,  FRadius , FCircleSteps),
             ReversePolygon( Circle(FCenter, FInnerRadius , FCircleSteps))];

from graphics32.

@lamdalili I am aware of the limitations of BuildPolyPolyline (when not using the clipper polygon builder) but I was concerned about the implications of the change for existing user code. I mean I can easily fix the color picker (which I just used as an example), like what you did, but I can't fix what other people have done in their code.

Now that I have thought about it some more I think that I should just apply the change again and deal with any problems it might cause in user code as support cases.

I'll reopen this issue as a reminder that I need to roll back the roll back.

from graphics32.

Are you sure this syntax is compatible with versions of Delphi supported by GR32

[Circle(FCenter,  FRadius , FCircleSteps),
             ReversePolygon( Circle(FCenter, FInnerRadius , FCircleSteps))];

from graphics32.

Are you sure this syntax is compatible with versions of Delphi supported by GR32

No, you right; It requires Delphi XE7. Sigh :-(

from graphics32.

I think I've made that mistake in several places but I guess I can fix those as/if they are discovered.
I just found 8 other instances by searching for ":= ["

from graphics32.

I think the easiest way to create an array constructor is by adding a new overload version of PolyPolygon in GR32_VectorUtils.. but without compiling the code in one of those old versions it is almost impossible to find them all

function PolyPolygon(const Points: array of TArrayOfFloatPoint): TArrayOfArrayOfFloatPoint;
var
 I, Len: integer;
begin
  Len := Length(Points);
  SetLength(Result, Len);
  for I := 0 to Len - 1 do
     Result[I] := Points[I];
end;

The challenge is how to detect other operations not supported by older versions, like the concatenation using the + operator.

I found that CatPolyPolygon which should in theory do this operation is not implemented correctly and seems to have never been reported or even tested

from graphics32.

I think the easiest way to create an array constructor is by adding a new overload version of PolyPolygon in GR32_VectorUtils..

I don't understand what good that function would do. Is it that const Points: array of TArrayOfFloatPoint is considered a const array instead of a dynamic array?

The challenge is how to detect other operations not supported by older versions

I'm mostly inclined to not do anything right now. I mean I don't even know if anyone is using the newer versions of Graphics32 with Delphi versions older than XE7. I'll be happy to fix it if anyone actually needs it fixed but before then it is potentially just a waste of time.
FWIW, XE6 was 10 years old a week ago, and XE7 will be 10 in half a year. It would actually be a good idea to have the limit on backward support defined by age instead of the current static limit at XE2.

I found that CatPolyPolygon which should in theory do this operation is not implemented correctly and seems to have never been reported or even tested

Ouch. Good catch. I have now deleted the two functions.
I can see that the functions originally came from VPR and were named `CatPolygon' so my guess is that the data types erroneously were changed by search and replace, even before they were merged into GR32.

from graphics32.

I don't understand what good that function would do. Is it that const Points: array of TArrayOfFloatPoint is considered a const array instead of a dynamic array?

May be not the best code, the main reason is that it allows replacing the existing code without any further modifications, just by adding the name of the function PolyPolygon([elm1, elm2])

The elements are placed in a temporary array but that doesn't matter since their number is very small usually inserted manually

Now I don't recommend it, curiously I took a look in the assembler I noticed that the function generates huge code not suitable for fast tasks

from graphics32.

Anyway, I'll close this one again and address the dynamic array stuff if anyone complains.

from graphics32.