> 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
