I've run into a strange problem with my OpenGL-based application. In certain circumstances, calls to glDrawElements() will take an unusually long time (around a second) to return. This seems to happen when textures with certain dimensions (e.g. 1024x1024) are bound. Strangely, it only seems to happen once per application run (once it's occurred, it doesn't occur again during that run of the program). Here's my setup: Intel(R) 82915G/GV/910GL Express Chipset Family Windows XP Professional Version 2002 Service Pack 3 1 GB RAM All indications are that the video drivers are up to date. Also, I do not observe the same behavior on my Mac (1.5 GB RAM, GeForce 2 TwinView). Querying via OpenGL indicates that the card supports the texture dimensions being used. I tried creating a minimal working example that demonstrates the behavior, but wasn't able to reproduce it; I'm guessing this is because the actual application loads quite a few textures, and the delay is somehow related to swapping textures in and out of video memory (that's just a guess though). My Google search turned up some discussion of video cards in the Express Chipset family having trouble with certain texture sizes, but no mention of the particular 'delay' behavior that I'm seeing. I haven't seen this behavior with other OpenGL-based applications running on the same system, which leads me to believe there's something about my particular application that's causing the behavior. It may be because my application currently uses a fairly large amount of texture memory (this is because I haven't yet added atlasing to my sprite rendering system). It still seems strange though that glDrawElements() would block for a whole second before returning. Has anyone else encountered this behavior? More generally, for what reasons might glDrawElements() take such a long time to return?