GDI/GDI+ creating paths

[Evan Stade]

Hi,

I was talking with Julliard about the implementation of paths in GDI+.
 He suggested that the right way to do it was to build paths directly
(i.e. not calling into GDI).  I'm not sure why calling into GDI is
undesirable.  There are several reasons I'd like to use GDI paths:

* GDI and GDI+ paths seem to behave exactly the same way
* this implementation of GDI+ calls into GDI for drawing, so it seems
natural to rely on GDI to create paths as well.
* unless we take rendering completely out of the hands of GDI, we need
GDI to draw paths for us because of line joins.  It seems strange to
me to draw shapes and draw paths with GDI, but not to create paths
with GDI.
* path.c in gdi32 is 2000 lines, and re-implementing it seems overkill

I don't see any drawbacks of calling into GDI to make paths, other
than a slight performance decrease introduced by an extra level of
indirection.  Can anyone suggest another reason why this approach is
flawed?

[Evan Stade]

On 6/26/07, Evan Stade  wrote:
> Hi,
>
> I was talking with Julliard about the implementation of paths in GDI+.
>  He suggested that the right way to do it was to build paths directly
> (i.e. not calling into GDI).  I'm not sure why calling into GDI is
> undesirable.  There are several reasons I'd like to use GDI paths:
> - GDI and GDI+ paths seem to behave exactly the same way
> - this implementation of GDI+ calls into GDI for drawing, so it seems
>
> natural to rely on GDI to create paths as well.
> - unless we take rendering completely out of the hands of GDI, we need
>
> GDI to draw paths for us because of line joins.  It seems strange to
> me to draw shapes and draw paths with GDI, but not to create paths
> with GDI.
> - path.c in gdi32 is 2000 lines, and re-implementing it seems overkill
>
> I don't see any drawbacks of calling into GDI to make paths, other
> than a slight performance decrease introduced by an extra level of
> indirection.  Can anyone suggest another reason why this approach is
> flawed?
>
> --
> Evan Stade

Actually line joins (the third bullet point) could be handled by using
gdi32.PolyDraw.
However the other points still stand.

[Alexandre Julliard]

"Evan Stade"  writes:
> I don't see any drawbacks of calling into GDI to make paths, other
> than a slight performance decrease introduced by an extra level of
> indirection.  Can anyone suggest another reason why this approach is
> flawed?

You can certainly use GDI, if you find a way to do it cleanly. But
your current approach feels like trying to fit a square peg in a round
hole.