<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [gallium] glCopyPixels is affected by enabled texture state" href="https://bugs.freedesktop.org/show_bug.cgi?id=96943#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [gallium] glCopyPixels is affected by enabled texture state" href="https://bugs.freedesktop.org/show_bug.cgi?id=96943">bug 96943</a> from <a class="email" href="mailto:imirkin@alum.mit.edu" title="Ilia Mirkin <imirkin@alum.mit.edu>"> Ilia Mirkin</a> <pre>(In reply to Roland Scheidegger from <a href="show_bug.cgi?id=96943#c1">comment #1</a>) > The piglit test is probably wrong (I didn't really look), at least different > results based on enabled texturing don't surprise me. This is one of the > more weird "features" of glCopyPixels(), glDrawPixels() and friends. > From the respective man pages: > "Texture mapping, fog, and all the fragment operations are applied before > the fragments are written to the frame buffer." So if you don't disable > texturing, you'll get texturing on top of your copied pixels (which just > represent the primary color), in whatever way the shader specified (albeit > the texture coords should be constant IIRC). OK, so in that case, any time that a texture unit is enabled, we should be falling back to the drawpixels-style shader? (The multiply, btw, is coming from the texture combine logic, which defaults to "combine" aka "multiply".)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>