gdiplus: bezier test question
The patch that I have just submitted ("gdiplus: fix the bezier arc path test (on all platforms).") is a simple fix for the failing test in graphicspath.c. The failure highlights gdiplus behaviour that is not directly obvious: If you have a bezier arc: static path_test_t arc_path[] = { {600.0, 450.0, PathPointTypeStart, 0, 0}, /*0*/ {600.0, 643.3, PathPointTypeBezier, 0, 0}, /*1*/ {488.1, 800.0, PathPointTypeBezier, 0, 0}, /*2*/ }; the gdiplus code will make the last entry PathPointTypeBezier | PathPointTypeCloseSubpath. For the nature of the existing test, I believe the fix is correct (it is testing the basic arc path functionality). However, there should be another test to document the above behaviour. - Reece
"Reece Dunn" <msclrhd(a)googlemail.com> wrote:
The patch that I have just submitted ("gdiplus: fix the bezier arc path test (on all platforms).") is a simple fix for the failing test in graphicspath.c. The failure highlights gdiplus behaviour that is not directly obvious:
If you have a bezier arc:
static path_test_t arc_path[] = { {600.0, 450.0, PathPointTypeStart, 0, 0}, /*0*/ {600.0, 643.3, PathPointTypeBezier, 0, 0}, /*1*/ {488.1, 800.0, PathPointTypeBezier, 0, 0}, /*2*/ };
the gdiplus code will make the last entry PathPointTypeBezier | PathPointTypeCloseSubpath.
For the nature of the existing test, I believe the fix is correct (it is testing the basic arc path functionality). However, there should be another test to document the above behaviour.
This behaviour matches what GDI32 does with adding PT_CLOSEFIGURE. -- Dmitry.
On 25/01/2008, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
"Reece Dunn" <msclrhd(a)googlemail.com> wrote:
The patch that I have just submitted ("gdiplus: fix the bezier arc path test (on all platforms).") is a simple fix for the failing test in graphicspath.c. The failure highlights gdiplus behaviour that is not directly obvious:
If you have a bezier arc:
static path_test_t arc_path[] = { {600.0, 450.0, PathPointTypeStart, 0, 0}, /*0*/ {600.0, 643.3, PathPointTypeBezier, 0, 0}, /*1*/ {488.1, 800.0, PathPointTypeBezier, 0, 0}, /*2*/ };
the gdiplus code will make the last entry PathPointTypeBezier | PathPointTypeCloseSubpath.
For the nature of the existing test, I believe the fix is correct (it is testing the basic arc path functionality). However, there should be another test to document the above behaviour.
This behaviour matches what GDI32 does with adding PT_CLOSEFIGURE.
Looking into the test a bit more, it is calling GdipAddPathArc to construct the path, and then ok_path is extracting the path data, checking that data against the exprected data. - Reece
participants (2)
-
Dmitry Timoshkov -
Reece Dunn