On Mar 4, 2012, at 15:07, Randy Ficker <randyfic...@gmail.com> wrote:
> Thanks for the explanation! > > When you get shared contexts working, can you share a sample app that shows > how to use them? Yes indeed! I'll probably upload a new sample tonight or tomorrow that works with 4.0.5. I'm already working on improving the interfaces to make this easier, as the current api and code doesn't help much with context sharing, so expect the next mfa update to bring some (non-breaking) api changes for this. > > 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. Yeah, it's a very annoying race condition that slipped through in this release. Use try/catch statements when calling those methods so your app doesn't crash as a workaround for now, that should be fixed on the next mfa update. ~~ andreia gaita ~~ scribled on my iPaddle > -----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, it’s pretty light on the >> details. I’d 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
