gdiplus: graphics tests [try2]

[Misha Koshelev]

> Am Freitag, 15. Juni 2007 22:02 schrieb Jan Zerebecki:
> > On Fri, Jun 15, 2007 at 01:36:09PM +0200, Alexandre Julliard wrote:
> > > "Evan Stade" <estade at gmail.com> writes:
> > > > +static const INT drawline_bmp1[192] =
> > > > +{0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xf
> > > > fffffff,
> > >
> > > I don't think we want to do that sort of thing. We can't guarantee
> > > that the results will be exact pixel for pixel, and we don't really
> > > care. And even if we did, hardcoding the image in the source this way
> > > is unmaintainable.
> > >
> > > If you want to check the results, you should write an app that draws
> > > various things and check it visually against Windows, but I don't
> > > think that's something that can be part of the regression test suite.

May I suggest something like enclosing your gdiplus function calls in a regression
test in a BeginPath(hdc) and EndPath(hdc) and then using GetPath to check that the paths 
created by your functions conform to those on native (you can take a look at what I am
using right now in dlls/gdi/tests/path.c and some expansions here http://www.winehq.org/pipermail/wine-patches/2007-June/040679.html).
I have found that it seems to be a good way to test at least the gdi functions without
having to compare the visual result pixel by pixel while still being able to test the
basic drawing primitives that are being used (btw you have to give the x&y coords +/- 1 or 2
when checking them b/c of floating point rounding diffs).

The only downside for using this kind of framework would be that if anything changes in gdi32's
path implementation it would affect your tests, but I think no matter what you do for a graphics
regression tests for gdiplus changes in gdi32 would affect it.

Just wanted to throw the idea out as I think a good conformance test is worth its weight in gold.

Misha

[Huw Davies]

On Fri, Jun 22, 2007 at 12:10:15AM -0500, Misha Koshelev wrote:
> > Am Freitag, 15. Juni 2007 22:02 schrieb Jan Zerebecki:
> > > On Fri, Jun 15, 2007 at 01:36:09PM +0200, Alexandre Julliard wrote:
> > > > "Evan Stade" <estade at gmail.com> writes:
> > > > > +static const INT drawline_bmp1[192] =
> > > > > +{0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xf
> > > > > fffffff,
> > > >
> > > > I don't think we want to do that sort of thing. We can't guarantee
> > > > that the results will be exact pixel for pixel, and we don't really
> > > > care. And even if we did, hardcoding the image in the source this way
> > > > is unmaintainable.
> > > >
> > > > If you want to check the results, you should write an app that draws
> > > > various things and check it visually against Windows, but I don't
> > > > think that's something that can be part of the regression test suite.
>
> May I suggest something like enclosing your gdiplus function calls in a regression
> test in a BeginPath(hdc) and EndPath(hdc) and then using GetPath to check that the paths 
> created by your functions conform to those on native.

Or better still draw onto an emf dc.  Of course you'd have to check that native
gdiplus doesn't do things differently in this case.

Huw.

[Misha Koshelev]

On Fri, 2007-06-22 at 10:44 +0100, Huw Davies wrote:
> On Fri, Jun 22, 2007 at 12:10:15AM -0500, Misha Koshelev wrote:
> > > Am Freitag, 15. Juni 2007 22:02 schrieb Jan Zerebecki:
> > > > On Fri, Jun 15, 2007 at 01:36:09PM +0200, Alexandre Julliard wrote:
> > > > > "Evan Stade" <estade at gmail.com> writes:
> > > > > > +static const INT drawline_bmp1[192] =
> > > > > > +{0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xf
> > > > > > fffffff,
> > > > >
> > > > > I don't think we want to do that sort of thing. We can't guarantee
> > > > > that the results will be exact pixel for pixel, and we don't really
> > > > > care. And even if we did, hardcoding the image in the source this way
> > > > > is unmaintainable.
> > > > >
> > > > > If you want to check the results, you should write an app that draws
> > > > > various things and check it visually against Windows, but I don't
> > > > > think that's something that can be part of the regression test suite.
> >
> > May I suggest something like enclosing your gdiplus function calls in a regression
> > test in a BeginPath(hdc) and EndPath(hdc) and then using GetPath to check that the paths 
> > created by your functions conform to those on native.
>
> Or better still draw onto an emf dc.  Of course you'd have to check that native
> gdiplus doesn't do things differently in this case.
>
> Huw.

Btw on the topic of drawing onto an emf dc, any idea why comparing emf's
byte by byte from native to wine doesn't work yet. Specifically, I am
wondering about the "different reasons" below (from
dlls/gdi32/tests/metafile.c):
> /* this doesn't succeed yet: EMF has correct size, all EMF records
>  * are there, but their contents don't match for different
>
> reasons.
>      */
>     if (compare_emf_bits(hMetafile, EMF_TEXTOUT_ON_PATH_BITS,
> sizeof(EMF_TEXTOUT_ON_PATH_BITS),
>         "emf_TextOut_on_path", TRUE) != 0)
>     {
>         dump_emf_bits(hMetafile, "emf_TextOut_on_path");
>         dump_emf_records(hMetafile, "emf_TextOut_on_path");
>     }

This is not just for the this particular EMF, as I tried some other GDI
functions (I am thinking of adding a few to emfdrv that are not there
but wanted to make a conformance test first). The other option seems to
be enumerating the EMF I guess, but compare_emf_bits would be nice if it
worked.

Thanks
Misha