OpenGL plugin crashes Chrome when the visible region is changed - google-chrome

Question

I'm developing a plugin using FireBreath on Windows (for now) that among other things is displaying a webcam feed using OpenGL. I'm using a windowed plugin and I'm drawing from a separate thread. The code can be viewed here:
Header file
https://github.com/EvilTengil/kinect-at-home-plugin/blob/0007beecf136ff2e5e1aa50be94d4906447a8f43/Win/KinectAtHomeWin.h
Source file
https://github.com/EvilTengil/kinect-at-home-plugin/blob/0007beecf136ff2e5e1aa50be94d4906447a8f43/Win/KinectAtHomeWin.cpp
(Ignore the strange code in onWindowResized, it's just some testing that remained in the commit.)
The problem is that as soon as the browser window is re-sized so that the visible region of the plugin is changed or the the extension is somehow scrolled outside the visible area of the scroll box, the plugin crashes in Chrome. I haven't got Firefox installed but I'm guessing it's a NpApi thing, since it's working in Internet Explorer.
I believe what is happening is that Chrome releases and creates a new HDC whenever the visible dimensions of the plugin is changed. This probably results in that the Rendering Context is invalid, but it is still being used in the plugin and that causes the crash.
I've noticed NPP_SetWindow get's called when this happens, but those calls are ignored in NpapiPluginModule_NPP.cpp, so my there is no way of hooking in to this event.
I've Google for several hours now but without finding any help. Does anyone have any experience of this?
I have an idea that it could work if I created my own child window to the plugin window where I could handle my own DC. I did some quick testing that failed, which is probably because of my lame Win32 skills. But could this work with some more work? Another idea I have is to track the visible region somehow, but I haven't looked in to this yet.

Answer 1

Windows handles getting invalid should not cause a program to crash per so. But OpenGL, namely its extensions require some special precautions, especially if the host program makes use of OpenGL as well.
Any kind of plugin or DLL that makes use of OpenGL must take care, that is puts its required resources into a sane state before using them, and put them back once done. For OpenGL this means, everytime before you start using it you should rebind your context:
HDC hOldDC = wglGetCurrentDC();
HRC hOldContext = wglGetCurrentContext();
// first unbind old context/DC from current thread
wglMakeCurrent(NULL, NULL);
// then bind our context
wglMakeCurrent(hMyDC, hMyContext);
// this is essential, as in Windows the addresses of extensions
// may depend on the active context, so you must reinitialise
// extension function pointers!
reinitialize_extensions();
/* NOW USE OPENGL FUNCTION
// cleaning up once we're done:
wglMakeCurrent(NULL, NULL);
wglMakeCurrent(hOldDC, hOldRC);
// remember that we also need to reset extension
// function pointers to the other context
reinitialize_extensions();
Since in Window extension functions pointers depend on the context it makes sense to put them into a structure and call them through that one. This saves the whole extension reinitialisation thing. In C++ you could wrap the whole OpenGL context in a class for this.
Remember that you need to go through this setup/teardown everytime your plugin gets called through NP-API.