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