[AGGPas] Problem with arc method and angle direction in unit agg_2D

[rchastain2]

Hello Graeme.

According to me, the issue described in this discussion isn't totally solved.

Here are images created by the same program, using in one case fpGUI sources, LCL in the other case.

It's an arc from 90 degrees to 360.

It seems to me that the LCL version is correct.

arc-test.zip

[graemeg]

OK, there's a lot going on. Short answer, based on that screenshot and your attached example, LCL's version is most likely still incorrect at the moment.

Issue 1:
You were correct that fpGUI's agg_2D.pas and Agg2D.pas had different results to what you expected. But let me try to explain. When the AggPas canvas attaches to the rendering buffer, we use a positive stride. Meaning screen co-ordinates and Y-down (Y increases downwards like your screen). AGG's Arc, Star, etc. followed that convention, Y-down. So 0 degrees at 3 o'clock and 90 degrees at 6 o'clock.

But when you compare that to GDI and Xlib APIs, they also use Y-down screen co-ordinates, but mathematical sweep angles (so they flip it internally). So 0 degrees at 3 o'clock and 90 degrees at 12 o'clock. What you and most others would expect.

So I went ahead and changed both agg units to match GDI and Xlib API behaviour, to prevent any further confusion.

Issue 2:
Now the big question, why is your example still not rendering what you expected, even with the latest fpGUI changes? With the updated fpGUI code, this is what your demo generates now:

90 degrees is still at the 6 o'clock position.

Your demo uses the standalone agg_2D.pas which has a different attach method to the fpGUI-enabled one. Look at line 57:

agg^.attach(@(FData[0]), FWidth, FHeight, FWidth * CColorW);

Positive stride — so Y-down in the rendering buffer. That's good! But then look at SaveToPng line 78:

y1 := FHeight - y - 1;

The PNG saving flips Y when reading back the buffer. So the image is rendered Y-down internally, but the final PNG output has Y flipped (bottom-to-top). This means an arc starting at 90° that was rendered at the 6 o'clock position (Y-down) appears at 12 o'clock in the saved PNG —which is what's seen above.

The fix is to read the image buffer top-down when saving to PNG:

  function getBufItemAsWord(ADelta: byte): Word;
  begin
    result :=
      Word(FData[x * CColorW + y * FWidth * CColorW + ADelta] shl 8) or
      Word(128);
  end;

resulting in:

Finally the expected result. 🙂

[rchastain2]

Thank you Graeme.

Indeed, with the latest develop branch, and the new getBufItemAsWord function, I get the expected result.

But while updating my examples, I fall on something else: now text is upside down.

It is this example.

[rchastain2]

But when you compare that to GDI and Xlib APIs, they also use Y-down screen co-ordinates, but mathematical sweep angles (so they flip it internally). So 0 degrees at 3 o'clock and 90 degrees at 12 o'clock. What you and most others would expect.

To be clear, I had believed that agg_2D used Y-up screen coordinates. That's why I expected 90 degrees at 12 o'clock. Now I understand that my SaveToPng method was wrong, and that agg_2D uses Y-down coordinates.

For me, both solutions (90 degrees at 12 o'clock and 90 degrees at 6 o'clock) are acceptable. IIRC correctly, Cairo has 90 degrees at 6 o'clock.

If I may say, I would prefer that we stick to the original design of the library (I mean AGGPas and also the C library). Now I have a doubt, because of the text upside down issue (and because I see that you have added minus signs here and there in your latest commit).

[graemeg]

When you attach the canvas to the image buffer, if you negate the sweep, it flips the Y co-ordinate. My copy of AggPas was actually matching the official C++ AGG behaviour. But yesterday's change now diverged from it. But I'm really okay with that (I think), because I've added AggCanvas (using aggpas) to match the behaviour of fpGUI's existing GDI and Xlib backends. I don't want to break backwards compatibility with fpGUI's existing code from many years.

If you actually take a closer look at the original AggPas website and the arc() api example:
https://www.crossgl.com/aggpas/documentation/index.html#Arc

Notice carefully, the code shows "Draw Arc from 45 degrees to 270 degrees". Now if you look at the output [screenshot] that was generated, the red arc started at the ~4:30 clock position ending at 12 o'clock, going clockwise. That's how fpGUI's version behaved too. Until yesterday. 🙂

[rchastain2]

Thank you for the explanation. All these changes in perspective are a little unsettling, but I imagine that with time I will get used to it. :)

I switched back to the first version of the SaveToPng method, because I cannot consider an image to be right-side up when the text is upside down. So finally, 90 degrees are again at 6 o'clock. :)

I didn't know that we could use a negative value for stride. (I confess I don't have a clear idea of what a stride is.)

I had hoped a convergence between LCL and fpGUI. At this point, here is where we are. We can consider this as a progress. :)

[graemeg]

I didn't know that we could use a negative value for stride. (I confess I don't have a clear idea of what a stride is.)

I'll not pretend to be a 2d graphics guru, because I'm definitely not. But I've learnt a few things over the years dabbing in graphics. But let me try and explain...

Think of stride (sometimes called "pitch") as the "width" of a single row of pixels, but measured in bytes rather than pixels.

It tells the computer exactly how many steps it needs to take in memory to move from one pixel to the pixel directly below it.

Why do we need it?

To a computer, an image isn't a 2D grid; it’s just one long, continuous line of data in memory. If you have an image that is 10 pixels wide, the computer sees 10 pixels of Row A, immediately followed by 10 pixels of Row B. So knowing the size of stride, helps the graphics library easily calculate how to get to row 2, or exact pixel co-ordinate.

The "Positive vs. Negative" Stride Trick

This is where it gets interesting for libraries. Since the computer is just following a map, you can "trick" it into changing how it draws the image by changing the stride value.

1. Positive Stride (Y-Down)
This is the standard modern way. The memory pointer starts at the "top-left" corner. To get to the next row, you add the stride value.

• Result: As the memory address increases, you move down the screen.

2. Negative Stride (Y-Up / Flipped)
This is a clever shortcut for flipping an image without actually moving any pixel data around.
Instead of pointing to the "top-left" of the image, you point the library to the bottom-left row. Then, you give it a negative stride.

• How it works: To get to the "next" row, the library adds the stride. If the stride is -100, it’s actually subtracting 100 bytes, which moves the pointer up to the previous row in memory.
• Result: The library thinks it's moving forward, but it's actually climbing "up" the memory bank, effectively flipping the image vertically.

[rchastain2]

Thank you Graeme.

I had another question about flipping an image. I created a new issue.