Re: [PATCH try2 4/4] gdi32: Call pMoveTo if available when emulating ArcTo/PolylineTo/PolyBezierTo.

[Alexandre Julliard]

Misha Koshelev <mk144210(a)bcm.edu> writes:
> This sends proper position information to the GDI driver when we are emulating these functions.

I don't think I agree with this one. If the driver needs to update the
position then it should implement ArcTo etc. since it may need to
distinguish that from an explicit MoveTo. Or if the generic
implementation is really good enough in all cases then we shouldn't
export a driver entry point at all.

-- 
Alexandre Julliard
julliard(a)winehq.org

[PATCH try2 4/4] gdi32: Call pMoveTo if available when emulating ArcTo/PolylineTo/PolyBezierTo.

[Koshelev, Misha Vladislavo]

I will have to investigate this further on native then (I'll look into making a fake driver that implements Arc and MoveTo but not ArcTo, call ArcTo on that driver and see what happens).
 
I don't know whether this is a valid case, but what I'm thinking of is a pre-Win2000 GDI driver (have to double check that that is a possibility...) that implements Arc but not ArcTo since ArcTo was only added in Win2000.
 
Also, I have some patches ready that test & conform AngleArc too (just using ArcTo since that's basically what an AngleArc is as well), so I'll send those out sometime today probably.
 
Misha

________________________________

From: Alexandre Julliard [mailto:julliard(a)winehq.org]
Sent: Thu 6/21/2007 9:11 AM
To: Koshelev, Misha Vladislavo
Cc: wine-devel(a)winehq.org
Subject: Re: [PATCH try2 4/4] gdi32: Call pMoveTo if available when emulating ArcTo/PolylineTo/PolyBezierTo.



Misha Koshelev <mk144210(a)bcm.edu> writes:
> This sends proper position information to the GDI driver when we are emulating these functions.

I don't think I agree with this one. If the driver needs to update the
position then it should implement ArcTo etc. since it may need to
distinguish that from an explicit MoveTo. Or if the generic
implementation is really good enough in all cases then we shouldn't
export a driver entry point at all.

--
Alexandre Julliard
julliard(a)winehq.org

[PATCH try2 4/4] gdi32: Call pMoveTo if available when emulating ArcTo/PolylineTo/PolyBezierTo.

[Alexandre Julliard]

"Koshelev, Misha Vladislavo" <mk144210(a)bcm.tmc.edu> writes:
> I will have to investigate this further on native then (I'll look
> into making a fake driver that implements Arc and MoveTo but not
> ArcTo, call ArcTo on that driver and see what happens).
>
> I don't know whether this is a valid case, but what I'm thinking of
> is a pre-Win2000 GDI driver (have to double check that that is a
> possibility...) that implements Arc but not ArcTo since ArcTo was
> only added in Win2000.

The GDI driver interface is purely Wine internal, it has nothing to do
with Windows drivers.

-- 
Alexandre Julliard
julliard(a)winehq.org

[PATCH try2 4/4] gdi32: Call pMoveTo if available when emulating ArcTo/PolylineTo/PolyBezierTo.

[Misha Koshelev]

On Thu, 2007-06-21 at 16:11 +0200, Alexandre Julliard wrote:
> Misha Koshelev <mk144210(a)bcm.edu> writes:
> > This sends proper position information to the GDI driver when we are emulating these functions.
>
> I don't think I agree with this one. If the driver needs to update the
> position then it should implement ArcTo etc. since it may need to
> distinguish that from an explicit MoveTo. Or if the generic
> implementation is really good enough in all cases then we shouldn't
> export a driver entry point at all.

Fyi I don't think we can get rid of the driver entry point b/c of the
case of enhmfdrv which needs to write the exact function call that is
made. Our implementation of enhmfdrv currently doesn't implement ArcTo,
and I would maybe implement one, but it looks like right now the
conformance tests for enhance metafiles are todo (our enhanced metafiles
don't match native byte by byte), so I'll have to see.

But in any case I think the function entry point definitely needs to
stay.

Misha