[AGGPas] Difference between fpGUI and LCL (arc method of agg_2D unit)

[Roland57]

The attached example (an arc filled with gradient) doesn't produce the same output, depending on whether we link to fpGUI or to LCL units.

You can use the included Makefile as follows:

Code: Bash  [Select][+][-]

1. make arc
2. make arc LCL=1

(You need to edit paths according to your installation.)

[wp]

In the LCL-AggPas, the arc is painted with the "strokeOnly" parameter, while in Graeme's it has "FillAndStroke". - I think I can change this in the LCL. But on the other hand, Delphi's and Lazarus' and fcl-Image's Arc draw the outline only, there's a dedication method for the filled arc ("Chord"). Maybe the most flexible option would be to provide an optional additional DrawPathFlag parameter (FillOnly, StrokeOnly, FillAndStroke, FillWithLineColor)

The other difference is that the LCL version seems to draw the arc in clockwise direction although the missing ccw parameter has the value true, i.e. counter-clockwise. The problem is that aggpas, in acc2d.arc, suddenly sets the ccw parameter to false (clockwise). Not sure if this is intentional (if yes, why didn't they default ccw to false in the first place?). Graeme seems to have decided to define this as a bug because his code exchanges the "start" and "sweep" angle parameters and thus makes the clockwise to a counter-clickwise. I personally think this way of dealing with the issue is confusing, and I tend to remove the ccw="false" argument from Agg2D.arg so that the default value of "true" will be used again.

[Roland57]

Thank you Werner for your investigation.

Probably I will create an issue in fpGUI repository, to be sure that Graeme see this discussion.

Meanwhile I made a more complete test program.

[Graeme]

intentional (if yes, why didn't they default ccw to false in the first place?). Graeme seems to have decided to define this as a bug because his code exchanges the "start" and "sweep" angle parameters and thus makes the clockwise to a counter-clickwise.

I'll have to check the git history for clues - it's been years. I do recall that because fpGUI used GDI and X11 api's years before AggCanvas was added, I adapted some agg2d code to match the behavior of GDI and X11 to some degree. That might have been one such case. In hindsight - if that was so - there definitely are better ways to handle that.

If I get a moment, I'll have a look.

G

[cdbc]

Hi Roland
<offtopic> Sorry for the break in
Sorry mate, my github broke over the last couple of days
So, here it is, can you please fork it as you see fit =^
Have fun...

Note: this package should compile with FPC 3.2.2 out of the box
No external dependencies, like before 
</offtopic>
Regards Benny

[Graeme]

In the LCL-AggPas, the arc is painted with the "strokeOnly" parameter, while in Graeme's it has "FillAndStroke".

I had a quick look. Regardless if there is FillAndStroke in the Arc() method. If you call agg.noFill before calling Arc(), it will not fill the arc. Using FillAndStroke in all the shape APIs just means I don't need to add additional parameters to all the methods, and you can still control if Arc() will render with stroke-only, fill-only or both.

[Roland57]

Thank you for the investigation Graeme.

I had a quick look. Regardless if there is FillAndStroke in the Arc() method. If you call agg.noFill before calling Arc(), it will not fill the arc. Using FillAndStroke in all the shape APIs just means I don't need to add additional parameters to all the methods, and you can still control if Arc() will render with stroke-only, fill-only or both.

I would agree on that point.

On the second point I would agree with @wp.

If it were my code, I would remove the default parameter value in the low level function:

Code: Pascal  [Select][+][-]

1. // agg_arc.pas
2. constructor arc.Construct(x ,y ,rx ,ry ,a1 ,a2 : double; ccw : boolean = true );

And I would put parameters in correct order here:

Code: Pascal  [Select][+][-]

1. // agg_2D.pas
2. procedure Agg2D.arc(cx ,cy ,rx ,ry ,start ,sweep : double );
3. var
4.  ar : {bezier_}agg_arc.arc;
5.  
6. begin
7.   // ...
8.  ar.Construct(cx ,cy ,rx ,ry ,sweep, start,false ); // <---

And change the boolean value (?).

While I was working on my clock example, I noticed that agg_2D and Agg2D use different convention: trigonometric for the one, antitrigonometric for the other. If it is a clear decision, why not.

Anyway please find an agreement with @wp, so that we can go forward. 

[Graeme]

Yeah, I didn't mention in my earlier message. I do agree about the inconsistent default, the unused `ccw` parameter (it never set the field variable), and swapped angle arguments do seem wrong.

It will all be fixed very shortly. :-)

[wp]

Modified the arc procedure in the LCL's aggpas to use the FillAndStroke parameter as suggested by Graeme. Modified the Construct method such that the ccw argument can be true, also in TAggFPCanvas.Arc. Renamed some misleading parameters (endangle instead of sweep) and corrected some comments (counter-clockwise vs clockwise). Added an incompatibility note to the Laz 5.0 release notes about the FillAndStroke parameter (https://wiki.freepascal.org/Lazarus_5.0_release_notes#aggpas_incompatibility).

[Roland57]

@wp

Tested your changes successfully. Thanks!

[Graeme]

For fpGUI's FillArc() which is totally the wrong name - so we learn.  Anyway, I noticed when AggCanvas was enabled, it didn't render a "filled pie" like GDI and X11 did. I created a new agg_2D.pas implementation which now matches the other platforms.

I'll start the deprecation of Canvas.FillArc() to become Pie() or something, so it more accurately reflects the implementation intent.

[Roland57]

Hello AGG friends.

The problem is still not (totally) solved.

Look at this arc from 0 to PI / 2.

For me, I would say that the LCL version is right.

@Graeme
Do you agree?