6

I am drawing circular arcs using the Windows GDI function Arc. It takes for arguments the bounding box of the circle and two points that delimit the starting and ending angles (not the angles themselves).

When I pass the arguments as below, I get an abnormal result. Instead of a quasi-flat arc of a circle with a large radius (about 13069, the bounding box is a square), I get the output as on the picture (rotated; the second version shows the placement of the two endpoints; the third is the expected output).

Arc(hDC, -25660, -12837, 477, 13300, 475, 462, 476, 66);

enter image description here

I suspect that the anomaly is due to the large radius/flatness of the arc, though the coordinates aren't so huge. Do you have any explanation ? My main concern is to find the conditions under which such noticeable features arise, in order to work around them.

Here is a simple console application that produces the problem:

#include <Windows.h>

int main(int argc, char* argv[])
{
    HDC hDC= GetDC(GetForegroundWindow());
    SelectObject(hDC, GetStockObject(WHITE_PEN));

    // Right
    Arc(hDC, -16, 37, 457, 510, 475, 462, 476, 66);

    // Wrong
    Arc(hDC, -25660, -12837, 477, 13300, 475, 462, 476, 66);

    return 0;
}
  • Are you sure there's no transformation defined? https://msdn.microsoft.com/en-us/library/dd183475(v=vs.85).aspx otherwise do you have a repro code? – Simon Mourier Nov 09 '15 at 23:16
  • @SimonMourier: yes, quite sure. Other arcs are drawn correctly. I have added sample code. –  Nov 09 '15 at 23:36
  • Playing with the map mode (http://wvware.sourceforge.net/caolan/mapmode.html) should fix the issue - difficult for me to test with your huge coordinates :-).The default is MM_TEXT which uses pixels as the unit. I suggest you use one of the LO or HI mm (https://msdn.microsoft.com/en-us/library/dd162980.aspx) – Simon Mourier Nov 10 '15 at 08:12
  • @SimonMourier: sorry, I don't believe that this can help. In the end GDI turns everything back to pixel coordinates, which would return to the same pixel values (with a probable loss of accuracy during the conversions to and fro). I know that my values are large, which could cause internal overflows. Anyway I have read somewhere that a range of at least 24 bits is supported (and I am below 15 bits). –  Nov 10 '15 at 08:24
  • Have you tried to add a SetMapMode(MM_LOENGLISH) for example after GetDC (and probably changed coords)? – Simon Mourier Nov 10 '15 at 09:12
  • @SimonMourier: How do I get the proper scale factor ? –  Nov 10 '15 at 09:22
  • I did find the way to convert; the MM_LOENGLISH coordinates are -28440,14243, 529,-1475, 526, -513, 528, -73. As expected, the output is exactly the same. Why do you think that the map mode could influence ? –  Nov 10 '15 at 09:39
  • Just a wild guess but it was difficult for me to test. There was this old 16-bit limitation of Arc shown here in 2003's MSDN: http://public.icefox.org:8080/msdn_2003_last/GDI/hh/gdi/linecurv_6uoz.htm but it was only for Win9x. And since your code does not even fall in this case (even in absolute value), it in fact validates it should be ok... I'm wondering if AngleArc also has this issue. There's also this very old text which exhibits some limits: http://195.19.138.139:3000/p/SOURCE/CSAMPLE/PETZOLD4.TXT – Simon Mourier Nov 11 '15 at 17:25
  • My guess is that the internal routine that calculates the start/end points by finding the intersections of the radii with the circle is different from and out-sync-with the logic that finds the control points on the circle to draw the arc using splines or whatever interpolation. This causes the starting point to fall "behind" the first control point and, combined with the spline smoothing, causes that noticeable artifact. – dxiv Nov 16 '15 at 05:00
  • Whatever the root cause, it's certainly a bug. Happens under Win 7 Sp1, Server 2012 R2, and Win 10 with the latest update. Seems closely related to the AngleArc bug reported here https://social.msdn.microsoft.com/Forums/vstudio/en-US/2538aa8b-49bf-4553-8b51-a84720409881/is-it-a-gdi-bug-about-anglearc-function as "curly hair". No resolution, or even insight, in that thread except that it works correctly in GDI+ (but of course GDI/GDI+ are already "discouraged" in favor of Direct2D by now https://msdn.microsoft.com/en-us/library/ff684176.aspx). – dxiv Nov 16 '15 at 05:00
  • @dxiv: I confirm that the same arc can be drawn correctly in Gdi+, but that's not so useful as the parameters aren't the same. –  Nov 16 '15 at 11:59

0 Answers0