OpenGL ES with GDI problem. (eglMakeCurrent - bug?)

Hello. I’m trying to use OpenGL ES in following scernario (testing on Dell Axim x51v): Create surface, context and etc. once but do not make current it. Then, on some event (WM_LBUTTONUP) I make it current and rendering runs (in usual way - if no message, render the frame). During rendering period, there is no any GDI drawing performed. When GL rendering completed (some kind of animation) I call eglMakeCurrent(dpy, 0, 0, 0) and detach the context. BUT I do not kill surfaces and context. Just detach it! After that, I draw in “normal” way again - using GDI drawing in WM_PAINT. BUT there is a BIG problem! Sometimes after detaching context drawing in WM_PAINT works FINE, but sometimes the last rendered by GL screen still visible (context detached!) and ANY drawing in WM_PAINT has NO visible result! Well, lets start GL rendering again. It may be that after it WM_PAINT will work fine, but may be not. So, after GL rendering and context detach WM_PAINT drawing do not works, and sometimes works. Any ideas? Is it bug or it should be this way?

There is some news. Lets change a bit (make a certainly wrong usage) my example. Lets create a surface, context and make it current. By default, let’s draw WM_PAINT. On sone signal, we would use GL. After animation ends, we draw in WM_PAINT again. Do not attach/detach a context! Result is the same! It’s obvious that now GDI and GL rendering fights for the video device! Sometimes GDI draws, sometimes GDI drawing has no effect. It seems like releasing current context DOESN’T enables us to draw with GDI, we MUST destroy the context. Is it right??? I thought that after I released current context (eglMakeCurrent(dpy, 0, 0, 0)) a can SAFELY draw using GDI. Am I wrong, or video device driver mad?

same problem here, any ideas?

I think you need to use the eglWait-primitives (eglWaitClient and eglWaitNative) to synchronize drawing with different APIs (GDI counts as native drawing - eglWaitNative). I don’t think the effects you describe makes much sense, but I don’t think they are violating the standard either. As far as I can read from the EGL spec, eglMakeCurrent is supposed to flush the API (but not wait for it to finish), meaning that there can take some arbitrary time to free up the graphics device.

Perhaps John has some light to shed here?

I solved this problem like this:

When I want to draw with GDI, I destroy the surface, but not the context!

eglWaitNative (EGL_CORE_NATIVE_ENGINE); //Not sure if this is needed.
eglDestroySurface( iEglDisplay, iEglSurface );

And when I want to draw again with OpenGL ES, I create again the texture:

if (!iEglSurface){
iEglSurface = eglCreateWindowSurface ( iEglDisplay, Config, hWnd, NULL );