The short question is: profiling tells that wglMakeCurrent takes ages (like 10ms each) under some conditions that we don’t control. What could cause it behave so? This is on various graphics cards from different vendors.
The long story: we make a web plugin for playing 3D content. It works ok in Internet Explorer; however on Firefox wglMakeCurrent is awfully slow. Exactly the same plugin works on Opera ok, so there must be something funky in Firefox that causes the slowdown. I’ve been wrestling this for months now and would really like to get it solved.
So far I did not get much response neither from Firefox (“it’s a driver problem!”) nor IHVs (“it’s a firefox problem!”). Both do not solve the actual issue though.
Here’s a minimal repro case: http://unity3d.com/aras/firefox_slow/WebPluginGLTest.zip (244KB) - basically the minimal plugins for IE (ActiveX) and Firefox (NPAPI) that do nothing, just 10 wglMakeCurrent calls each frame, clear and swap buffers. The instructions are in readme.txt file inside, along with full source code and compiled versions.
I’ve seen machines that are not slow in Firefox; but most I’ve tried are slow (both Firefox 1.5 and 2.0; graphics cards like GeForce 6800/7600, Radeon 9600/X1600 etc).
Did anyone else have experience with wglMakeCurrent being slow? Under what conditions it is?
Your post accidentally helped me to solve 20% performance drop mystery in my game.
I wanted to check if Firefox uses OpenGL for anything and therefore produce some battle for rendering context with your plugin. The idea was to copy glIntercept’s dll to firefox directory, and then I’ve noticed that I left glIntercept enabled in my game’s directory.
Now back to your question. Honestly I have no idea what’s going on, but it’s unlikely to be a driver issue. My bet is on Firefox.
For example - when I open one page in Firefox (one of polish portals) I get 10-80% CPU usage. And that’s ONE page on Athlon64 3200.
There are 4 flash animations there, so I tested IE - 10-60% CPU usage.
Then I scrolled to the bottom of page, so no animations were visible - 10-70% on firefox and 0-2% on IE.
I know - this is only one example and it’s about handling flash animations, but it’s allready saying something.
At work I have 800MHz cpu and sometimes firefox stops responding for more than 10s.
Sometimes mouse wheel reacts with more than 10s delay, but I can scroll the page by draggin scrollbar in the meantime and very often after right click no popup menu appears until I move the mouse. This is just how firefox is written.
So, ironically, one could say that having only 10ms of delay you actually got lucky.
Well, but the time is spend inside wglMakeCurrent, which is in the OpenGL driver. Of course, maybe the issue is that Firefox is doing something wrong that confuses the driver. And that is my question: what can Firefox do to make wglMakeCurrent slow?
Even if it’s Firefox’ or driver bug (the latter being unlikely; unless all drivers by all IHVs have this bug), I still have to find the workaround. When people see slow stuff in our plugin, they surely won’t start blaming Firefox
Setting the pixel format of a window more than once can lead to significant complications for the Window Manager and for multithread applications, so it is not allowed. An application can only set the pixel format of a window one time. Once a window’s pixel format is set, it cannot be changed.
glIntercept does not indicate any errors (nor does glGetError). I am using CS_OWNDC (but at least in this case using it or not using it does not make any difference). I am setting the pixel format only once.
