Vincent Povirk wrote:
This is a very simple drawing test that I've created to establish a precedent for drawing tests in gdiplus.
Gdiplus currently has no tests that draw things and then check what was drawn. I've added some functions that should make this easy. It's important to get this right the first time so any feedback will be most appreciated.
As for me I'm not against it if it'll work stably, but will this really help? It's much easier to check this visually, comparing with native output. These pixel-by-pixel tests should use current bpp depth for 'relaxation' when we start draw gradients for example...That's will add another complexity. Maybe it makes sense to add an antialiasing drawing tests to find out a closer algorithm for line drawing with different SmoothingModes...
As for me I'm not against it if it'll work stably, but will this really help? It's much easier to check this visually, comparing with native output.
I think it will help. It should be stable as long as we are careful about how strict the tests are. It's probably not as appropriate to be this strict most of the time.
In this particular test, I think we can expect pixel-accuracy. By default there is no antialiasing, and the shape is a rectangle. Similarly, if we draw a raster image at integer coordinates, we should get a consistent result.
Checking things visually is not easy for me. It requires me to write a test program or find an existing program that uses a particular call in the way I want, and I don't trust myself to do the test without mistakes. It does not fill me with confidence that anything in our current implementation is correct. When I'm looking at a bug that could be caused by any of a number of functions (because I'm not sure of the correct behavior), tests help.
These pixel-by-pixel tests should use current bpp depth for 'relaxation' when we start draw gradients for example...That's will add another complexity.
I'm not sure what you mean.
The current bpp depth shouldn't be an issue if I've done this right. It should do 32-bit tests regardless of the display.
Maybe it makes sense to add an antialiasing drawing tests to find out a closer algorithm for line drawing with different SmoothingModes...
I'm still stuck on the question of how we can implement antialiasing while relying so heavily on gdi32.
Vincent Povirk
Vincent Povirk wrote:
As for me I'm not against it if it'll work stably, but will this really help? It's much easier to check this visually, comparing with native output.
I think it will help. It should be stable as long as we are careful about how strict the tests are. It's probably not as appropriate to be this strict most of the time.
In this particular test, I think we can expect pixel-accuracy. By default there is no antialiasing, and the shape is a rectangle. Similarly, if we draw a raster image at integer coordinates, we should get a consistent result.
In this particular test definitely yes.
Maybe it makes sense to add an antialiasing drawing tests to find out a closer algorithm for line drawing with different SmoothingModes...
I'm still stuck on the question of how we can implement antialiasing while relying so heavily on gdi32.
Here I mean GdipDrawLine, for example, for Graphics with SmoothingMode set. We can use LineTo or antialiasing computing each pixel, it isn't a point. --- P.S. there's no place for todo_wine in you expect_pixel.
P.S. there's no place for todo_wine in you expect_pixel.
You can write todo_wine expect_pixel(...);
-
Nikolay Sivov -
Vincent Povirk