Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report for Bug 28176 on
Developer Community or GitHub if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
Created attachment 10404 [details]
Project that demonstrates the issue
Timer created with Xamarin.Forms.Device.StartTimer stops receiving notifications after a while, when running on iPhone 6 iOS 8.2. To continue receiving notification one has to tap on the screen. This behavior is easily reproducible when the time spent in the notification handler roughly equals the notification interval.
Simple test project that demonstrates this issue is attached to this bug report.
Xamarin forum discussion: http://forums.xamarin.com/discussion/36071/problem-with-xamarin-forms-device-starttimer
I can confirm running into this issue as well whilst trying to set up a timer to rotate an image at a given interval.
It appears that this is a correct behavior for an IOS timer that invokes a CPU intensive procedure. In fact i believe that Xamarin's timer is directly linked to scheduledTimerWithTimeInterval. Which indeed stops firing after a while, when it's callback is CPU intensive (most probably to keep GUI responsive).
I would note this in the documentation to avoid further confusion.
For a CPU intensive task i would recommend using either threads or ThreadPool. This is what i did in my case to resolve this issue.
@Ed, I can't come up with a test case using Xcode and Objective-C that shows the same behavior. Do you have an example?
Created attachment 10836 [details]
Demo project based on Foundation.NSTimer.CreateScheduledTimer
I posted another project that exhibits the same behavior. It's based on Foundation.NSTimer.CreateScheduledTimer.
I will check in Xcode later today. I guess in Xcode it's less likely to reproduce because Xamaron.Forms introduce additional overhead over the UI run loop on their own?
In both cases the timer actually keeps running (you can set a breakpoint to prove it), but the UI doesn't update. That's the behavior I couldn't reproduce without Xamarin.Forms. I'm not certain it's a bug yet, but something about how Xamarin.Forms triggers UI updates seems to make this worse. Maybe it's just that much more CPU time. I don't know. I wish I could trigger it without Forms to be confident it's not something that could be fixed.
Created attachment 10846 [details]
Xcode swift project, similar GUI updating loop, runs smoothly
Adam, you are absolutely right. The timer still gets called, but GUI stops being updated. I checked this with Console.WriteLine("..") calls. I also created a swift project in Xcode with similar GUI updating loop, and it runs smoothly (attached to this bug report). So, I guess there is indeed something wrong under the hood in Xamarin.Forms. Reopening this issue.
Created attachment 10852 [details]
iOS app with native interface
I tried the same GUI updating loop in an iOS app with native UI, no issues. So, i guess there is really an issue with Xamarin.Forms.
In fact, in the app i am currently developing, even after i moved all heavy stuff into ThreadPool there is still stuttering from time to time. And the more controls on the screen the more likely interface will intermittently freeze.
Created new thread on Xamarin.Forms forum http://forums.xamarin.com/discussion/38843/label-value-is-not-updated-when-inotifypropertychanged-property-changes#latest
Hope this one gets attention from Xamarin team.
I was able to reproduce this with the project linked in the forum post from Comment 11.
Just a note why i would consider this bug critical. What happens here is that updates to GUI are being lost and this leads to a situation when GUI is not synchronized anymore with the underneath model.
Ed, thanks for taking the time to bring this issue to our attention. Very interesting issue!
I would expect Forms to be able to update a bindable property at greater than 60hz and have Forms ignore updates between the 16ms refresh periods. So that if in 16ms the property is set to A, then B, then C that forms would ignore A, and B and only do heavy work when it's decided to render C. We'll do further investigation but I'd expect that we're simply doing to much work after each update (A and B) and not optimizing for the case where the value is simply going to be overridden by a new value (C) before the next layout.
To help us prioritize optimizing this use case can you tell us why you need to update a bindable property 1000x within a 16ms (60hz) window given that the user will only see 1 out of 1000 of the values?
Xamarin Forms Team
Chris, i made this loop in the test app to make this bug 100% reproducible, otherwise it's intermittent in our application.
Since you say that that issue might be due to the GUI thread being overloaded and thus skipping values, i assume that transferring parameters from the main thread to the GUI thread is done through some kind of queue? Probably a workaround would be keeping the lastly set value for a property in that queue while pushing out the others? Just guessing.
As for the priority for this issue, i tried hard to mitigate this issue in our project, but it still remains of a high priority for us, since it still manifests itself from time to time, not that frequently though as it was before.
It might become a real problem after it triggers to its full extent and becomes intolerable due to the changes we constantly do to our application.
There's a test app attached. Did you try that on a recent iOS?
This was mistakenly closed
This repros on 10.3 in the simulator. Timers are created every 20ms that should range between 0.0-1.0s, but the UI is updated like every 4 or 5 seconds.