1

I have a case where UIPickerView didSelectRow messages are only sent after a long delay. In some cases, they don't get sent at all.

Context: my app is doing some heavy, animated compute and rendering stuff during the time when the user would spin the wheel to select something. You can spin the wheel and it looks like it's working correctly; however, when a row is selected, the didSelectRow message takes several seconds to reach my delegate. And occasionally, my delegate never receives a message.

Clearly, it has something to do with the compute load. The thing I don't understand, though, is why the messages can't "sneak through" between frames. Don't these messages get queued somewhere?

If they don't get queued, is there any way to poll the picker between frames?

Anna Dickinson
  • 3,307
  • 24
  • 43
  • Is your intensive rendering (which I assume is via OpenGL ES from your tag here) being performed on the main thread? If not, but it's still jamming up your UI elements, you may be running into the issue described in this question: http://stackoverflow.com/questions/5944050/cadisplaylink-opengl-rendering-breaks-uiscrollview-behaviour . I mention a solution I use in my answer there, and touch events do seem to be preserved when doing that. – Brad Larson Aug 18 '12 at 19:41
  • The whole app is single-threaded; or, at least, my code isn't intentionally launching other threads. I think my problem is the opposite: the frame rate of the rendering doesn't change -- it's just the picker which gets jammed up. Your problem was UI element updates delaying your render updates (unless I'm misreading it...) Any idea about how to implement polling? That might be the easiest thing... – Anna Dickinson Aug 19 '12 at 13:31
  • If your OpenGL ES rendering is all on the main thread, it will mess up refreshes to your UI elements. That's why I proposed doing OpenGL ES rendering on a background serial GCD queue. It works both ways, allowing for smooth UI updates as well as uninterrupted computation and rendering, and is what I'd recommend for your case based on my experience. You'll also see a huge overall performance boost on the multicore iOS devices by doing this. – Brad Larson Aug 19 '12 at 15:07
  • Yes, the more I thought about it, the more I realized that the app should be multithreaded for a bunch of reasons. What's GCD? – Anna Dickinson Aug 19 '12 at 20:05
  • GCD: http://en.wikipedia.org/wiki/Grand_Central_Dispatch – M-V Aug 20 '12 at 07:04
  • Ahh, ok. That's a little heavy-weight for what I'm doing; but, I think I managed to figure it out. Looks like all I need to do is run glDrawArrays in a background thread. Very few code changes required. – Anna Dickinson Aug 20 '12 at 16:16
  • @BradLarson Ok, I think your comment answered the question... so, if you want to put it as an answer, I can click the green check! – Anna Dickinson Aug 20 '12 at 16:40
  • Hmm.. changed my mind. Turns out it's the computation -- not the rendering -- which is causing the problem. I could run the rendering in another thread easily enough, but not the computation. Basically, I need the didSelectRow message to interrupt my computation loop. – Anna Dickinson Aug 21 '12 at 20:55
  • Continued and answered (more or less) here: http://stackoverflow.com/questions/12063063/uipickerview-preemptive-messages – Anna Dickinson Aug 25 '12 at 00:53

0 Answers0