iOS Move openGL ES to its own thead?

iOS
#1

I’m trying to wrap my head around the EAGLView in OF and how openGL is drawn. I’m currently having an issue where UIKit elements are sometimes slow and I’m curious if it’s because openGL is drawn on the main thread and it’s slowing down the UI calls. From what I understand, it’s best to leave the mainThread for UIKit elements and move openGL and other things to another thread.

Has anyone tried this or have tips how OF could be modified to move openGL so another thread? Or is that what displayLink is already doing (has it’s own thread)?

#2

I’m still testing, but this looks like it could be a good candidate for core integration.

It has examples of threaded, single (what we currently use), and GCD (which I think is iOS 4.0 only) openGL implementation: https://github.com/Volcore/LimbicGL

The main example classes are here: https://github.com/Volcore/LimbicGL/tree/master/limbicgl/drivers

I was able to implement the Threaded example into OF, but I’m still testing. So far it seems a lot better. Loading new UIViewControllers or UIViews no longer stall the openGL or audio thread. It does delay the menu from loading right away (if it takes time to load), but it’s better than stalling the whole application.

I’m not sure I’m integrating it entirely right though so it would be great if someone could help review. There’s currently some [glView lock] and [glView unlock] commands that I can’t figure out. I don’t think they actually do anything, do they?

I can post the code in a few.

#3

This sounds interesting and helpful-- any progress on it?

#4

Somewhat, but I think I’m doing something wrong because it occasionally crashes on startup. I can post my code in a day or two.

I did notice that the [glView lock] and [glView unlock] is a method of threading, but I think the examples above fully implement it.