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 on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 1410 [details]
test1 application, crash log during rotation
If application contains a few UITableViewControllers that are nested in UINavigationControllers. It crashes on iPad 1 quite fast during rotation.
The same code in objc works really well. Animation is even faster.
Created attachment 1411 [details]
test sources with a code that reproduces a crash
Debug on iPad 1. Start an application and perform a few rotation from landscape to portrait mode.
Expected result: application works, during rotation nothing is created in code.
Actual result: application is crashed with low memory warning.
Igor, we can duplicate the issue (performance and crash).
Can you send us (attach and mark it private if needed) the objc code you're comparing to ? thanks!
https://github.com/raweng/StackScrollView this is the original objc code. c# might have some minor changes, but layout and main functionality is the same.
Thanks for the ObjC sample. I adapted your sample to be closer to the ObjC sample and the problems went away, i.e. no more crash and better performance (identical to ObjC version - which is normal since the animation code is done by iOS).
This match what we have seen in HeapShot and Instruments. MT memory usage is low and stays low. There are no allocations (by the application itself) before receiving the memory warnings - meaning something else is doing the allocation (iOS itself).
The reasons for this is that your sample adds (on top of the ObjC sample) some code and controls that requires quite a bit of work for the device, like shadows and colors with alpha channel. That adds quite a bit of work and memory requirements (to compose) and this hurts the original iPad since it has only half the memory (256mb) of the iPad2 (and a single core versus a dual core CPU).
E.g. (in test1ViewController.ViewDidLoad)
menu.NavigationController.Toolbar.Alpha = 0.7f;
rightSlideView.Layer.ShadowColor = new CGColor(0, 0, 0);
rightSlideView.Layer.ShadowOffset = new SizeF(-2f, -2f);
rightSlideView.Layer.ShadowOpacity = 0.4f;
lineView.BackgroundColor = UIColor.FromWhiteAlpha(0f, 0.25f);
lightLineView.BackgroundColor = UIColor.FromWhiteAlpha(1f, 0.25f);
E.g. in UIStackScollView.LoadWorkspace
navControllerWorkspace.View.Layer.ShadowColor = new CGColor(0, 0, 0);
navControllerWorkspace.View.Layer.ShadowOffset = new SizeF(-2f, -2f);
navControllerWorkspace.View.Layer.ShadowOpacity = 0.4f;
navControllerWorkspace.View.Layer.CornerRadius = 5;
I suggest you degrade gracefully the usage of above UI effects, at least when executing on the iPad 1st gen devices. That will allow iPad2+ users to get the most beautiful experience while allowing iPad1 users to use your application.
Thanks Sebastien! Can you provide your modified sample? I want to be sure we cover all necessary modifications.
Created attachment 1418 [details]
solution with commented shadow/alpha code
hmm... I deleted it too quickly :-( but it was not hard to redo and I could do it cleaner this time by adding compile-time `#if false | #endif` on my changes (but it could easily be changed to a runtime flag to avoid running it on iPad1).
The solution works great. Thanks!
Glad I could help :-) Have a great release!