Thanks for the explanation! When you get shared contexts working, can you share a sample app that shows how to use them?
Also, I noticed that if you Finish() an activity that contains a GL view, OnRenderFrame and OnUpdateFrame are called at least once after the graphics context is disposed. I see "call to OpenGL ES API with no current context" logged and calling MakeCurrent() or SwapBuffers() throws an InvalidOperationException in this situation. -----Original Message----- From: Andreia Gaita [mailto:andr...@xamarin.com] Sent: Sunday, March 04, 2012 5:37 AM To: Randy Ficker Cc: monodroid@lists.ximian.com Subject: Re: 4.0.5's OpenTK overhaul Hi, On Sat, Mar 3, 2012 at 10:48 AM, Randy Ficker <randyfic...@gmail.com> wrote: > The release notes for 4.0.5 mention that this release brings an > overhauled OpenTK/Android backend. However, its pretty light on the > details. Id like to hear more about what exactly is changing. The objective was to try and fix as much as possible without breaking compatibility with existing code. The initialization code was rewritten, the context is now created earlier, the lifecycle of the context and surface now obeys the android rules (you can only touch a surface between SurfaceCreated and SurfaceDestroyed), and other things of that nature. For the most part, those should not affect user code, which is why they aren't mentioned in the release notes. > I installed this from the beta channel and I notice that all of the > OpenGL code now runs on the UI thread, as opposed to 4.0.4 where all > of the OpenGL code ran on its own dedicated thread. > > This is a pretty major change, so I was surprised it was not mentioned > in the release notes. This means that if a GL view is running at a > low framerate, all of the native controls on the screen now behave > very slowly as well, unlike in 4.0.4 where they were independent of > each other. Is this intentional? No, the runloop runs separately, in its own thread. Only the callbacks are made on the UI thread, following the common behaviour of OpenTK and also Android's GLSurfaceView. User code should be as efficient as possible during these callbacks, to minimize UI delays. You can do your own background threads for other expensive operations, if needed. There's been a report of the run loop running slower than requested, so there's ongoing work to make the runloop more efficient and closer to the requested fps. There's also some technical difficulties envolved with creating shared contexts, so we'll try to make those easier (because they're very useful). Anything else you find that needs improving, let us know. --- andreia gaita _______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
