The actual refresh rate is unaffected at a verified 60FPS with a CADisplayLink. The little demo I made is drawing just two triangles with 10-15% CPU. It is only the touch that is not being updated, when I animate programmatically there is no lag at all even with unrelated touch tracking happening simultaneously. I think that somehow the MusicPlayer framework causes the thread that tracks touch (which I had assumed was the main thread) to wait on the audio render cycle. What's interesting is that the main thread doesn't get blocked, only the updating of touch events. I know that AUGraph (which is utilized by a MusicSequence by default) can block, but I don't know if that's what's happening.
Dave On Thu, Feb 19, 2015 at 1:04 PM, Steven Clark <[email protected]> wrote: > If you have limitless CPU cycles then it would be a weird interaction. > It sounds very very much like the sort of behavior you get if there aren’t > enough CPU cycles for everything, and the system is optimized for something > other than what you’re trying to do. > > > > I had serious trouble with an iOS app that needed to track finger movement > and display video at the same time. It appears that iOS prioritizes > tracking movement over anything else (at least, anything else that the app > was doing). The video got really choppy etc. whenever you’d move your > finger, and clear up immediately when you move your finger away. I found > that the tracking loop was running as fast as it could, at the expense of > all other computation. (The system is optimized for visual user > interaction responsiveness.) I solved the problem by having my tracking > routine do nothing and return immediately something like 4 times out of 5. > Response to finger movement was slightly affected negatively, but video was > substantially improved. I might have solved it by increasing the priority > of the video processing thread, but that would have involved screwing > around with Mach thread prioritization and hoping the app would still be > approved by Apple for iTunes. > > > > Steven J. Clark > > VGo Communications > > > > *From:* [email protected] > [mailto:[email protected]] *On > Behalf Of *Dave O'Neill > *Sent:* Thursday, February 19, 2015 3:21 PM > *To:* Ian Kemmish > *Cc:* [email protected] > *Subject:* Re: MusicPlayer with OpenGL interfere with UIGestureRecognizer > > > > Really what I'm trying get to the bottom of, bug or no bug, is how can > these three seemingly unrelated api conflict? > > On Thursday, February 19, 2015, Ian Kemmish <[email protected]> > wrote: > > > On 18 Feb 2015, at 17:00, "Dave O'Neill" <[email protected]> wrote: > > > Once you see it being choppy press the play/stop button and see how > > the choppiness stops. Weirdest bug ever. > > Unless the gesture recognition software you're using is documented as > making guarantees about latency, then it's not a bug. It's life. > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Ian Kemmish 18 Durham Close, Biggleswade, Beds SG18 8HZ > [email protected] Tel: +44 1767 601361 Mob: +44 7952 > 854387 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/oneill707%40gmail.com > > This email sent to [email protected] > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
