[v3 PATCH] gdi32: Support Begin/End Path for metafile DCs

Dmitry Timoshkov dmitry at baikal.ru
Tue Feb 16 06:04:00 CST 2016


Huw Davies <huw at codeweavers.com> wrote:

> > > > diff --git a/dlls/gdi32/path.c b/dlls/gdi32/path.c
> > > > index e09cd0b..166b6b2 100644
> > > > --- a/dlls/gdi32/path.c
> > > > +++ b/dlls/gdi32/path.c
> > > ...
> > > > @@ -1513,6 +1523,14 @@ static BOOL pathdrv_ExtTextOut( PHYSDEV dev, INT x, INT y, UINT flags, const REC
> > > >      struct path_physdev *physdev = get_path_physdev( dev );
> > > >      unsigned int idx, ggo_flags = GGO_NATIVE;
> > > >      POINT offset = {0, 0};
> > > > +    DWORD type;
> > > > +
> > > > +    type = GetObjectType(dev->hdc);
> > > > +    if (type == OBJ_METADC || type == OBJ_ENHMETADC)
> > > > +    {
> > > > +        PHYSDEV next = GET_NEXT_PHYSDEV( dev, pExtTextOut );
> > > > +        return next->funcs->pExtTextOut( next, x, y, flags, lprc, str, count, dx );
> > > > +    }
> > > >  
> > > >      if (!count) return TRUE;
> > > >      if (flags & ETO_GLYPH_INDEX) ggo_flags |= GGO_GLYPH_INDEX;
> > > 
> > > Why the special treatment for ExtTextOut()?  I can believe we
> > > may need to do something with Begin/EndPath, but why this?
> > 
> > According to the tests a path on metafiles just creates a EMR_EXTTEXTOUT
> > record instead of generating a bunch of actual path representation records.
> 
> But isn't that just because we only test ExtTextOut()?  For example, we
> don't even test the contents of the emf created in test_emf_GetPath().

That's a good point. EMF contents get tested in test_emf_ExtTextOut_on_path()
and test_mf_ExtTextOut_on_path() though. Alistair, please add a test for EMF
contents in addition to what GetPath() returns, see other tests how to do that,
there is a helper that will generate appropriate data for you.

> What I'm wondering is whether we need to do this to more than just
> ExtTextOut.

That's also a good point, but it would be a separate effort I'd guess.

-- 
Dmitry.



More information about the wine-devel mailing list