Native Development

[BGmot]

>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.

Tried all

>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.

[smcveigh]

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?

[BGmot]

>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. -)

[BGmot]

>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. -)

[smcveigh]

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.

Cheers,
Sean

[BGmot]

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!

[smcveigh]

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.

Cheers,

Sean

[smcveigh]

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.

[BGmot]

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.

[smcveigh]

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.

Cheers,

Sean

[BGmot]

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.