Hi,
I'm not sure if this is particularly a windows-specific problem, but I have an application which uses creates multiple open gl windows (on multiple threads) in the same process (in an explorer shell extension actually). There's no issue with multithreading as each window essentially hosts it's own individual context, but I'm hitting a roadblock in the number of instances that I can run at any given time before the whole program slows to a complete crawl.
In the window initialization process, we create a standard open gl window (using the wgl bindings), and on destruction, we make sure to destroy the render/device contexts, shutting down gdi, free all textures and display lists, and destroying the atl window as well (all of this is per window, the process keeps running in the backgroudn). Unless wgl is limiting the number of possible contextes a process can create, or something similar, I am completely confused as to why this slowdown is occuring.
Some interesting notes: it appears that the size of the window, as well as the pixel format affects the number of windows I can create without slow down. For example, running full screen with multisampling will cause the lag within six window instances (opened and closed sequentially, no instances running in parallel), where as creating a basic open gl window will yield roughly twenty window instances before slowing to a crawl.
Could it be possible that it is somehow falling back to software mode? And if so, how would I tell? I'm not so sure this is the case because we are only drawing boxes (maybe 100 instances at most, also using display lists) on a Core2duo 2.0 ghz/ati x1600... which should be more than enough horsepower.
What other limits could I be hitting? Would this be a win32/opengl/wgl/ or hardware limit?
Thanks
