https://bugs.freedesktop.org/show_bug.cgi?id=89586
--- Comment #25 from Dan Sebald <daniel.seb...@ieee.org> --- I will attach an initial attempt at a Piglit test suite for glPixelZoom() in combination with glDrawPixels(). I tried (but failed) to set something up in which if a test fails the associated image is displayed for a couple seconds, but there is no good way in the framework of creating a delay. As with modern design for program flow, there shouldn't be any type of linear pause. Given that, it would take a bit to make registered callback functions work to recursively called tests because of the way the piglit_display is defined. Changing that is too much work/modification for this new test. Not even sure that is worth doing because big delays in rendering are usually a nuisance. The thing to do would be making each test a separate rendering, but that could be a lot of C files. In any case, if there is a failure, one has to manually pre-compile out most of the code, i.e., #if 0 .. #endif to make the failed test the last image displayed. For now, I've done that and assembled the images in PNG files for convenience. Originally I had put the test in tests/general/zoom-pixels.c to complement tests/general/draw-pixels.c, then moved it to where I.M. suggested, tests/spec/gl-1.0/pixelzoom.c. I've created several tests, and I attempted to make them specific yet not too specific (such as matching exact expected values) as to not cause any false negatives due to numerical effects. The tests are: 1) Monotonicity: With an input image in which one dimension is 2.5 times GL_MAX_TEXTURE_SIZE there is a ramp function for the RGB components of RGBA. Hence the output image should be a ramp. If it isn't, then that is a failure. This will catch the type of problem I originally ran across in which vertical lines are appearing in the image due to dropped pixels. This test is done for both x and y dimensions and for both positive and negative scaling factors. 2) Exact value at the edge: Using the OpenGL formulas, I derived the needed scaling factors to make the last pixel of the input image correspond to the last pixel of the output image. With that same ramp image from the previous test, the last pixel of the ramp is 1.0, so the last pixel of the output should be 1.0. Formulas are slightly different for positive and negative scaling. We can discuss whether this test is accurate. (More later.) 3) Scaling over or underrun: One thing I want to test is what I'm calling "overrun" or "underrun", which means that the output image falls one pixel too long or one pixel too short of its expected size. This effect can often be seen when resizing the output image (e.g., using the mouse to resize a window via a corner). That is, for some non-whole number numerator/divisor scalings, it might be that the pixel zoom indeces aren't working out right because of some inexact formula (e.g., the problems I saw in the original problem for swrast-legacy). What this test does is draw successive rectangles using an input image all of the same intensity but decrementing the zoom width or height and alternating the input image intensity. The residue left for each iteration is a single line, so when the process nears the end, the result is a framebuffer image of alternating lines. If that isn't correct, then for some zoom factor along the way there was a mistake. This is done for both directions, both postive and negative scaling factors and both magnification and condensation... I've had to put a small tolerance in the test for pixel values in the over/underrun tests. Does it work that the driver sets the value as close to, say, 0.25 as possible, and then returns what the actual value is? E.g., say the driver is 7 bits, so the resolution is 1/2^7. (Incidently, every driver returns an exact value for 1.0?) OK, please give this test suite a try and let me know what you think. I'm sure adjustments need to be made, and we can discuss the validity of the tests with regard to the OpenGL standard formulas, and refine them if warranted. Here is a summary of the results I'm currently seeing and a few comments. I've made screen captures and assembled the results into collective bitmaps so there aren't so many individual files. The four different drivers are as follows: (1) swrast-legacy: The repository legacy swrast_dri.so driver for which my system and others is using and exibits vertical lines. (2) swrast-legacy-patch: The legacy swrast_dri.co patched with the changeset I originally attached to this bug report. (3) swrast-gallium: The repository Gallium/llvm swrast_dri.so driver. (4) swrast-gallium-patch: The Gallium swrast_dri.co patched by removing the line of code that limits the size of the image. TEST (1) (2) (3) (4) ---- positive monotonic x fail pass fail fail positive edge x fail pass fail fail positive over/underrun x fail fail pass pass negative monotonic x pass pass fail pass negative edge x fail pass fail fail negative over/underrun x fail fail pass pass positive monotonic y fail pass fail fail positive edge y fail pass fail fail positive over/underrun y fail fail pass pass negative monotonic y pass pass fail pass negative edge y pass pass fail fail negative over/underrun y fail fail pass pass * Note that the Gallium driver behaves better than the legacy swrast for modifying the window size. Try maximizing the Piglit display window, or dragging the corner. Gallium driver scales quite nicely, but not legacy swrast. Gallium driver is a little faster as well. The image summary will appear labelled as follows (download the files and view as 1:1 or "normal size", otherwise there will be bad aliasing effects): SWRAST_DRI.SO LEGACY This is the current repository version of the legacy swrast driver. The first image (upper left corner) shows the original problem I and others had experienced: vertical lines due to dropped pixels associated with GL_MAX_TEXTURE_SIZE transition. Interestingly, this doesn't happen when xfactor is negative (one of the "pass" tests). The Y-direction exhibits a good gradient ramp, except for the very last pixel in the positive direction, which is missing (look for the dark line near the top of the window), so this test fails for reasons different than in the X direction. The positive over/underrun with magnification X test actually looks good, and I don't know why the test is failing. These things can be looked at in greater detail later. The other three over/underrun tests in the X direction clearly show that glDrawPixels isn't zooming to the right scale. This is the other potential bug I've wondered about. SWRAST_DRI.SO LEGACY PATCH With the Mesa changeset I attached to this bug report, the legacy driver now produces good results as far as the monotonicity tests. The vertical lines due to the GL_MAX_TEXTURE_SIZE boundary are gone in the X direction, and the positive Y-gradient image no longer has a missing last pixel (line). So that is making progress. However, it's clear that the changeset has solved the issue with glDrawPixels not scaling precisely, and I still don't see why the positive X/Y over/underrun tests are failing--the associated images look correct. SWRAST_DRI.SO GALLIUM The test images illustrate how the Gallium/LLVM driver is not displaying anything beyond the GL_MAX_TEXTURE_SIZE boundary of the input image. For all four monotonicity tests, only the darker portion of the gradient appears and from there it is the last draw/render that remains in the frame buffer. E.g., the Positive Monotonicity Y image still has the vertical alternating lines from the Negative Over/Underrun X test. It's no wonder all the monotonicity and edge tests fail. But the good news is that for input images with sizes less than GL_MAX_TEXTURE_SIZE, the Gallium driver is accurate for scaling. That's very nice. SWRAST_DRI.SO GALLIUM PATCH By making that simple change in src/mesa/state_tracker/st_cb_drawpixels.c that allows the driver to proceed if the input image size is greater than GL_MAX_TEXTURE_SIZE, I've found that the Gallium driver will complete the monotonic image grandients and generally looks good except for the last pixel (line) missing for both positive X and Y tests. Again, this is just an initial investigation, so we aren't sure yet whether there is a shortcoming in the test algorithm, or whether the Gallium driver might not be meeting the OpenGL standard for glDrawPixels() exactly, e.g., a boundary condition isn't being satisfied such as pixel centers on the left or bottom box boundary are considered in the box. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
