I recently noticed that the Win2K performance monitor was indicating memory leaks in a GL app. VC++'s built-in leak detection shows no problem, and neither does a third party leak detector. I tracked it down to the GL display lists. Now, there are only 3 lists in this program. If conditions change such that the list needs to be regenerated, the existing list is deleted first w/ glDeleteLists. This ALWAYS happens- the call to delete lists is in a setter function, the actual GLuint list data members are protected and can only be accessed through the setter - you know the drill.
Performance monitor indicates an increase in the apps’ private bytes every time the lists are regenerated. Comment out the few lines that generate the lists so the code executes without benefit of the lists, and there is no leak.
The red book says that the list memory is associated with the rendering context. The app in question can flip GL viewports from one side of a splitter to another. Doing this involves destroying and recreating the display window, and sure enough, if I flip the views to opposite sides of the splitter performance monitor indicates the memory has been freed.
So, the question - anyone ever seen this? Is it something I should be concerned about, or is this just windows way of managing the released display list memory? Or is most likely a bug in my code? As I said, I can’t see how it’s possible that glDeleteLists is not being called when approriate.
Any tips appreciated.