Bug 89624

In the following two bug reports:

https://bugs.freedesktop.org/show_bug.cgi?id=89586
https://bugs.freedesktop.org/show_bug.cgi?id=89622

I discussed some artifacts concerning pixels at or beyond GL_MAX_TEXTURE_SIZE in the input image.  In the first bug report I attached a patch that fixes the vertical lines in legacy swrast.  In the second I simply noted that Gallium swrast limits the image, and I think it wouldn't be too difficult to correct that.

Here I want to point out the subtle difference between legacy swrast (post patch in bug #89586) and the Gallium swrast using images with only 20 x 20 input pixels.

For legacy swrast, the attached image Screenshot-differences_legacy_swrast-annotated.png shows how the scaled image can extend past the edge of the boundary in the x-dimension, or not (and it never falls short of the boundary).  On the other hand, the image will fall short of boundary in the y-dimension, or not (and it never extends past).  I'm guessing this behavior has to do with xfactor > 0 and yfactor < 0.

For Gallium swrast, the attached image Screenshot-differences_gallium-annotated.png illustrates that scaled image aligns with the x-dimension edge (an it always seems to do so).  However, the image can extend past the bottom in the y-dimension, or not (and it seems to never fall short).

Since these two behaviors are different, as subtle as it may be, at least one of them has a bug.  I suspect that both of them might have a flaw as far as precisely following OpenGl standard.  It's interesting that the x-dimension for the Gallium driver seems most consistent.

Granted, the axis box itself may not be exact, so to say exactly what the bug is at this stage is premature, but at least the behavior of the axis box should be the same when all that is varied is the graphics driver and not the application binary.