Reputation: 1198
I'm using a fairly trivial OpenGL rendering pipeline - just taking some textures and rendering them to a RGB8 render buffer using GL_TRIANGLES. Some portions of the render buffer are not covered and remain as glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
. No alpha, no depth, etc. The code itself is kind of long to reproduce here, but it's a slight variation of gl-image-masher.
The strange thing is that I would expect the portions of render buffer not covered by render buffer to remain solid black. But in fact, there are some pixels near the triangle edges that are not black, but of value (0,1,0) or a permutation of that (out of 255 max). It's visually imperceptible, but black has a special meaning in my render buffer. It looks like this:
(with true black substituted by white). The same happens when primary background is white or purple (255,0,255) - some pixelss will be (255,1,255) or (255,0,254) etc.
I tried to modify the fragment shader to output a fixed color, and the effect was pretty interesting, with the stray pixels clustering only near coordinate skips:
The artifacts appear even with GL_LINES instead of GL_TRIANGLES, with variously sloped edges, with dithering and anti-aliasing disabled.
I'm wondering if this is something I do, some OpenGL optimization I should turn off, or even a driver bug? (This is with fglrx drivers 14.4.2 on Linux, the card is Radeon HD 7800 family.)
Upvotes: 2
Views: 226
Reputation: 1198
Sorry, I forgot to answer this, but I should.
So, this turned out to be an extremely silly error - in the somewhat convoluted pipeline, the output became a JPEG file (even though that's not the format I eventually opened it in GIMP with, that'd have hopefully struck me). And this mess around the edges is an obvious JPEG compression artifact then.
The JPEG file compression level was set to "100". But that still makes for a lossy compression, although with just +-1 in pixel values.
Upvotes: 1