OpenGL texture contains bad data - what's going on?

Question

I am trying to load an image into OpenGL texture.

I created a window and GL 4.4 Core Forward-Compatible context:

Here's the code I'm using to load the image and create the texture:

load :: IO ()
load = do
    image <- JP.readImage "image.png"
    case image of
        (Left err) -> do print err
                         exitWith (ExitFailure 1)
        (Right imgData) -> do 
            a <- malloc
            glGenTextures 1 a
            texId <- peek a
            free a
            loadImgIntoTexture texId imgData

loadImgIntoTexture texId (JP.ImageRGBA8 (JP.Image width height dat)) = do
    glBindTexture GL_TEXTURE_2D texId
    unsafeWith dat $ glTexImage2D GL_TEXTURE_2D 0 GL_RGBA (fromIntegral width) (fromIntegral height) 0 GL_RGBA GL_UNSIGNED_BYTE . castPtr
    --p <- mallocBytes $ (fromIntegral width) * (fromIntegral height) * 4
    --glTexImage2D GL_TEXTURE_2D 0 GL_RGBA (fromIntegral width) (fromIntegral height) 0 GL_RGBA GL_UNSIGNED_BYTE (castPtr p)
    print "everything ok"

The commented out line is another attempt to put anything meaningful into that texture.

Here's what gDebugger reports for the texture information:

And here's what it shows for the texture contents:

When I print out the structure returned by JuicyPixels, it prints out distinct byte sequences that most certainly don't produce a flat image.

In this example I'm not rendering the texture, and I'm using raw binding generated by the gl package. I had exactly the same behaviour (with the same shade of teal) when using OpenGL package. It unsurprisingly rendered as a flat rectangle on the screen.

I have tried with different images, sized 128x128 and NPOT (100x100 as in the screenshots).

What could be causing that behaviour?

Full source.

Answer 1

This is most probably the bug in gDEBugger. After some manipulations and actually drawing the texture, I've verified that it indeed contains the right data.

Answer 2

Combining the highly functional Haskell with OpenGL, the poster child of messy state, is tenebrific at best, and therefore I confess to being a little over my head with this exact scenario.

However, it is well-known that OpenGL textures are incomplete without both a minification filter and a magnification filter that match the data (see here). I didn't see such in the code, so your texture is incomplete. In C, you would add something like:

glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);

As pointed out in the comments, this probably shouldn't be causing gDEBugger to give bogus output; skimming the documentation, I didn't see anything that requires textures to be complete to be read from (and gDEBugger works by intercepting GL calls anyway). Still, reading from a texture with mismatched sampling filters feels wrong to me; I wouldn't be surprised if it's an edge case.