I am building a UITableView-based Unity plugin which will be embedded by game developers into their Unity app. I am using the standard approach with dequeueing reusable cells, and the UITableViewCells contain simple UILabels and a UIImageView. The image inside the UIImageView is loaded via an asynchronous request.
There are no usability issues at all when launching the plugin as a standalone Objective-C app (in particular, scrolling works well with no lag) but when inside Unity, there is a "sticky" scrolling issue which arises randomly, i.e. the view scrolls but without inertia. I have not been able to pinpoint the exact actions which cause this behavior, but it happens usually when I scroll very quickly in one direction, or in short movements back and forth. The bug disappears when I scroll the view past the top or bottom (trigger the "bounce" effect, I am guessing this causes some hard refresh).
There is a very similar issue described here. The fix they suggest is to put
#define USE_DISPLAY_LINK_IF_AVAILABLE 0
inside the Unity-generated AppController.mm file. Unfortunately, this fix is unfeasible for the game developer who will be integrating our plugin, since it turns off the fastest and most reliable timing solution, and would require a fallback to other timing systems which would cause the game itself to lag or miss a portion of touch and accelerometer events.
I will most likely override drawRect for the UITableViewCells to reduce rendering time and memory usage, and if that fails, write a version of the plugin in OpenGL. However, I was wondering if anyone had a similar issue and knows a quicker fix, either in Objective-C or inside Unity, that is non-destructive (like the timing fix described above). Thanks very much.
I had the same trouble that you have described. I've fixed it by commenting the line
//#define USE_DISPLAY_LINK_IF_AVAILABLE 0
Related
I am having a problem with iOS scrolling on an iPad. Every other platform tested works just fine. I love iOS, but hate it too. I was able to get the entire iframe contents scrolling within the parent, but there are two DIVs that are fixed that shouldn’t scroll within the iframe.
Before I spend a lot of time trying to work this out, I am just looking to leverage everyone’s experience for whether it, in fact, CAN be done. If it IS possible, then I will proceed to trying to work out a simple model and report it back for others. If experience shows that it can NOT be done, then you will all have saved me a lot of headache, not to mention time.
Here’s a drawing of what works on all other platforms but NOT iOS:
Simple question: Is it possible?
The simple answer is, in fact, YES.
I used to have a UITableView in a UIViewController. I would put a UIRefreshControl on the UITableView and on the very last bit of swiping down to refresh, the UITableView would quickly jump down.
All answers voiced the same: Undocumented/unexpected behavior (being able to use UIRefreshControl with a UITableView) yields such results. To mitigate this, I used a ContainerView to embed a UITableViewController in a UIViewController.
I have nearly solved this issue, but... if I swipe down slow enough, the problem persists.
Is there any way to mitigate this, or am I forced to live with it?
Video: http://streamable.com/8suq
Notice the first few times I swipe down look absolutely fine because I do it fast enough, but towards the end of the video I really slow it down and you notice the jump in question.
I notice that you have a mouse cursor in that video. You cannot judge graphic performance for animations in the simulator, it will not perform the same as on an actual device.
On a device you will get much better performance and a much better frames per second rate. I've seen this to be very noticable when using SpriteKit whilst learning to develop games lately.
I've only used the UIRefreshControl a couple of times previously in a UITableViewController and not noticed any major issues before. Since then I've been using other libraries such as https://github.com/samvermette/SVPullToRefresh.
Try your app on a physical device and in the meantime I will try to replicate your issue and add my findings in here
Having an issue with UIPickerView not spinning (iOS7/8), floating around left and right uncontrolled, being barely usable only when tapping on its values (and still horrible even then). It must be due to one of the library references, but I'm yet to figure out what exactly is causing it. The easiest way to reproduce it is by dropping a UIPickerView into one of the pages controlled by SLPagingView (https://github.com/StefanLage/SLPagingView) - screenshots included.
Just trying to see if anyone experienced this every with this trivial control?
The issue was in one of the referenced rogue libraries that overrode some of the default behavior by extending built-in controls and data types.
After excluding them one at a time from the project, cleaning it, and rebuilding, I eventually found the culprit.
I have an iOS App that uses Unity3D. When I pause Unity to show only Quartz-related content, the performance is usually fine.
But on a current project, scrollviews and table views sometimes perform very bad. They stop scrolling too early, and the scrollview stops even between multiples of the size predefined by the paging.
I tried to take a look with Instruments, and found FPS is usually ~50-60, but sometimes less. However this does not answer my question.
Btw, the table and the scroller have only a few data, and there is no reloading issue.
Okay, now I found some very helpful information at the Unity Forum. Using
#define USE_DISPLAY_LINK_IF_AVAILABLE 0
prevents the described issue. The Unity-iOS project now uses THREAD_BASED_LOOP instead of the CADisplayLink class. Maybe I will further play around with CADisplayLink and lower target frame rates.
Some interesting information about the used Rendering Loop Type can be found in the Unity Manual.
I have this problem with performance of my iPad app..
For developing, I use MonoDevelop, which takes care of Garbage collecting. Still my questions are rather generic, I'd say.
OK, I use TabBarController with 5 NavigationControllers. Inside nav controllers there are some controllers, whose views are TableViews or ScrollViews. Next child is always just regular view.
I have a few questions:
1) TableViews never scroll smoothly. I have some alpha transparency, but since I did my graphics in Photoshop and not programmatically, this transparency should not cause much problems. It doesn't matter whether I have few or many results in table.
On the other hand, I have ScrollView which serves same purpose, i.e. to be a table with different layout and buttons have Photoshop generated transparency as well. It works perfectly.
For tables I applied DequeueReusableCell() which works fine (I see that memory usage is not increasing after scrolling). So why would tables scroll so jerky?
2) My app supports rotation. When I scroll table or scrollView and simultaneously tilt the device a bit, I get maybe 1 or 2 FPS. What is the best way to implement rotation? As I understand, ShouldAutorotateToInterfaceOrientation has to be overridden in all controllers in NavigationController chain. Also, I need to add observer in View I want some changes to happen. Do I have to use BeginGeneratingDeviceOrientationNotifications() in all views or is it enough to do it in Main.cs? Maybe this slows it down?
3) After some time app starts getting memory warnings and then crashes eventually. I tried to read logs and run app with Instruments, but can't find the cause of crash.
4) What exactly happens to a View popped from NavigationController stack? I can't reuse it. But could it be that Monotouch (or me) doesn't dispose it correctly?
I have almost same app for iPhone without support for rotation which never crashes. I think I'm doing something wrong with this rotation, but I'm not sure what.
Any help will be appreciated the most. So, thank you in advance.
Regards
1 - transparencies are always a problem. Even if you're not rendering the images in code, the phone still needs to do the compositing of the image, and that may take a lot of time. UITableViews have to calculate the final composite image every time a new cell is displayed, or the table is scrolled, while UIScrollViews can calculate only once, since the image won't change. So be very careful about it, turn the transparency off, and check if performance improves.
2 - You shouldn't need to notify every uiview in your application. Receive the notification in the controllers that you want to update only, like for example if you want to rearrange items in the UIViewControllers view.
3 - you have one (or many) memory leaks. My guess is that MonoTouch probably can't garbage collect UIViews or UIViewControllers, because they're still being linked from somewhere in UIKit, like a UINavigationController
4 - UIViews are not disposed by UIKit until the app gets a memory warning notification.
Like Eduardo said, alpha transparency in Views comes at a price. There are some tools that you can use to identify the bottlenecks discussed in these WWDC 2011 talks from:
https://developer.apple.com/videos/wwdc/2011/
iOS Performance and Power Optimization with Instruments
Understanding UIKit Rendering
In the "Debug" menu of the iOS simulator you can find various debugging tools that will color different regions of the screen indicating where some problematic rendering is taking place. The WWDC 2011 talks show what you can do to fix those problems.
For your memory problems, it is very likely that you have something pointing out to your objects around, so you need to make sure those objects are gone. While we currently are not shipping our new profiler for MonoTouch that can show the source of the problem, I wrote a "poor man's" debug utility that will help you narrow down which objects are alive. It is available here:
http://tirania.org/tmp/HttpDebug.cs
Call HttpDebug.Start () from your application and as you run, connect with a web browser to http://localhost:5000 to get a list of live Objective-C objects surfaced to C#. The tool is not perfect and shows a lot of irrelevant data, but it would at least give you an idea of what is going on.