GDI/GDI+ creating paths

Evan Stade estade at gmail.com
Tue Jun 26 15:39:00 CDT 2007


On 6/26/07, Evan Stade <estade at gmail.com> 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.

-- 
Evan Stade



More information about the wine-devel mailing list