Member Avatar for Skeen

So I'm working with OpenGL, and DevIL to load some JPEG into my program, and I've had some trouble, I've isolated the program in a simple sample program (uploaded), the program is, that when I load the standard file, that came with the guide ("Geeks3D.jpg") it loades instantly and runs with a CPU usage of 0%, however if I load my own file, I'm getting like a heavy lag, before it loads, and then 100% CPU usage.. My question is, WHY!?

I've uploaded the source code, to change between using: "Geeks3D.jpg" and "Test.jpg", simply comment out "#define _PICTUREONE", in "cdemo.cpp".

The project is made in DevC++, and if you're wanting to use help me out, and only got VC laying around, simply compile with;

freeglut (glut will do)
glu32 
opengl32 
winmm 
gdi32

devil
ilut
ilu

Any help, or idea is welcome, kinda hoping to get this to work soon! :)

Project.zip (507.7 KB)
  • 1 Contributor
  • 1 Reply
  • 120 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by Skeen

Dani AI

Generated

The behavior you described — one JPEG loads fine, another causes a long stall and then very high CPU usage, but forcing the texture size to 128/256 fixes it — is a strong diagnostic clue.

Older drivers and GPUs that lack true non‑power‑of‑two (NPOT) support commonly perform a software conversion (rescale or padding) when you call glTexImage2D on an NPOT image. That conversion can be expensive and shows up as high CPU usage. Another common cost is an implicit format/resampling when using helpers like gluBuild2DMipmaps, which can do software work as well.

Practical checks and fixes

  • Verify NPOT support at runtime. Example (works on GL <=2.0-style contexts):

    const char* exts = (const char*)glGetString(GL_EXTENSIONS);
if (exts && strstr(exts, "GL_ARB_texture_non_power_of_two")) {
    // NPOT supported
}

  • Ensure the pixel alignment matches your data to avoid extra copying on upload:

    glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
glTexImage2D(..., width, height, ..., GL_RGBA, GL_UNSIGNED_BYTE, pixels);

  • If the GPU lacks NPOT support, either scale images to the nearest power‑of‑two before uploading (use DevIL/ILU to rescale), or update drivers/hardware that support NPOT.

Memory/leak checklist

  • After uploading the image to GL, free DevIL image handles (for example with ilDeleteImages) and free any pixel buffers.
  • Delete GL textures with glDeleteTextures when no longer needed.
  • Avoid regenerating textures every frame; load once and reuse.

Testing: instrument times around ilLoadImage, any DevIL rescale, and glTexImage2D. That will pinpoint whether the CPU spike is in DevIL, the driver conversion, or elsewhere. These steps explain why saw the problem disappear for 128/256 textures and give concrete checks and fixes.

Member Avatar for Skeen

So it works, if I fix the resolution into a byte like value, like 128, or 256, ect.

However it still seems like it memory leaks

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.