Re: gdiplus: graphics tests [try2]

[Alexandre Julliard]

"Evan Stade"  writes:
> +static const INT drawline_bmp1[192] =
> +{0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,
> - 0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,
> - 0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,
> - 0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,
> - 0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,

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.

gdiplus: graphics tests [try2]

[Jan Zerebecki]

On Fri, Jun 15, 2007 at 01:36:09PM +0200, Alexandre Julliard wrote:
> "Evan Stade"  writes:
> > +static const INT drawline_bmp1[192] =
> > +{0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,
>
> 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.

We already have visual tests in e.g. dlls/d3d9/tests/visual.c . I
suppose similar tests are acceptable for gdiplus?

Jan

gdiplus: graphics tests [try2]

[Stefan Dösinger]

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"  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.
>
> We already have visual tests in e.g. dlls/d3d9/tests/visual.c . I
> suppose similar tests are acceptable for gdiplus?

The d3d tests do not check the exact rendering results. Most of the time they 
test between two extremes, like light on and off, by drawing something that 
has extreme results in both cases, like complete black, or complete red. That 
result affects a big rectangle on the screen usually, like 1/4th or the 
entire screen.

Those tests do not depend on pixel exactness, and they don't test the visual 
result really. They rather check the result of a formula, or if an effect is 
active. But due to the nature of 3D rendering the only way to test this is to 
read back from the screen.

Currently the visual test hardcodes exact color values(with the exception of 
the fog test), just because it worked and its easier than fuzzy color 
matching. But the tests do not depend in any way if the resulting color is 
0x0000ff00 or 0x0000ee00 or 0x0010f005, as long as its not very far from the 
expected results. Also usually 100 and more pixels position displacement are 
ok, except of the texbem test, which was written to test bump mapping which 
operates in rather small dimensions.