08-14-2012 12:21 PM
>So if I understand - you're trying to set a native non-gl window to live BEHIND the opengl window?
Tried to put it IN FRONT with the same result.
>You should try out the different SCREEN_PROPERTY_TRANSPARENCY modes just to be sure.
>Also, you need a screen_flush_context() after setting the properties on screen_win_gles.
RIght, missed that I have two different contexts, corrected this but still win_gles is not transparent.
Thanks for your thoughts on this.
08-14-2012 12:48 PM
You shouldn't need 2 contexts, fyi. You can use the same context.
Have you tried using a pair of non-GL windows to confirm your setup?
08-14-2012 01:52 PM
>You shouldn't need 2 contexts, fyi. You can use the same context.
I also was confused with 2 contexts but this is how it is done in the example I am trying to follow.
>Have you tried using a pair of non-GL windows to confirm your setup?
I'll create separate app to play around and to prove this theory (OpenGL and Native can happily coexist), you'll add it to samples if it works. -)
08-14-2012 02:53 PM
I've asked the screen guy, and his question was "is there a call to screen_post_window() on screen_win ?"
Might be helpful if you could share a minimalist standalone sample in it's entirety.
08-14-2012 10:05 PM
Holy cow it works! I can even make OpenGL drawings semi-transparent...
The code is here https://github.com/BGmot/NativePlusOpneGLWindows
Now I have to think how to apply these findings to my apps. I am still not 100% clear on the infinite event cycle: can you clarify please why do we need to constantly (in even handling loop) update buffer size, position, screen size, zorder and visibility?
Next question: what does screen_flush_context() actually flushes for OpenGL window - empty window and then eglSwapBuffers() fills the window with contents or it makes visible everything that was put by OpenGL into this window.
Kind of missing connecting part between EGL and Native -(((
In any case - thanks a lot for your attention!
08-14-2012 11:32 PM
You don't need to constantly update the geometry. You only need to do it once.
And you need to flush the context in order to make the geometry changes "commit". All of the screen property changes are only cached locally until you flush them down to the driver.
Posting a window is another type of flushing operation. The reason you were likely having trouble before is that the child window will not become visible until after the parent is actually posted.
EGL just lives inside a native window. There is nothing special there. the eglSwapBuffers() call I believe is just doing the same as the window posting function.
08-14-2012 11:37 PM
Hmm.. . think you need to look at what the example you used as a starting point does. My guess is that it was a window animation which was updating the geometry every time a POST event was seen.
08-14-2012 11:41 PM
Yes, bar_win would need to be constantly updated as it is 'moving' but why all other windows are updated too? Trying to understand logic.
08-14-2012 11:51 PM
It's certainly not necessary unless you are moving or resizing windows. I can't speak as to what the original sample code is meant to do as I don't have time to dig around. Have to get BB10 finished! Glad you are off to a good start though. Just start stripping out unnecessary stuff.
08-15-2012 11:01 PM
I've done lots of code clean up and the app looks much simpler now, would be nice if somebody from RIM put this https://github.com/BGmot/NativePlusOpneGLWindows into Samples at github, it'll probably save some time for other people who decide to combine OpenGL and Native windows.
Thanks again for all support you've provided.