I'm trying a basic experiment where I add a grid of squares to a macOS ScreenSaver view (created through the Xcode template). I am running on a reasonably well performing MacBook Pro, but for some reason, adding my grid (composed of ~900 NSView objects) completely locks up my system — the screen saver hangs.
This isn't an unreasonable amount of views, surely? What's interesting is, I've tried the exact same layout in a macOS app (drawing in its NSWindow), and the performance is totally fine.
What is the difference?
What was causing the performance problem was that all the views were layer-backed. Once I stopped requesting the view to have a layer, performance improved dramatically.
I also went so far to use CAShapeLayer instead for improved animation performance.
Related
I have an problem with Xcode 6 really responding very slowly to user interactions, e.g. editing code, scrolling areas etc. This particularly happens when the interface builder show the view controllers with constraints in the storyboard (4/14 vcs has constraints i just begin the project) additional i use extra monitor.
I'm wondering if there is anything I can do to improve performance changing xcode options or other way.
My development machine is a MacBook Pro Retina (Retina, 15-inch, Late 2013) with 2.3Ghz Intel Core i7 and 16 GB RAM (1600 MHz DDR3), running OSX 10.9.5 (Mavericks).
Do you use an external monitor? If yes, probably that's the problem. Try moving to the main macbook screen and try again.
That solved the problem for me.
EDIT: sorry, just read you have an external monitor. So yes, move to the main screen and check if that solves the problem.
EDIT 2: seems like Apple fixed the problem, no more issues using my external monitor!
EDIT 3: meh! Problem persists, not sure why it stopped happening, and happens again now.
I had this same problem where performance plummeted on an external display.
What I ended up discovering was that the external monitor issue was indicating that there was a UIView that interface builder couldn't quite figure out properly for auto-layout.
In my case it was a UIToolbarBarItem that contained a UIView that contained a UILabel. Once I removed the offending UIToolbarBarItem the performance issue resolved itself. It went from being completely unusable to smooth scrolling.
You should check if you have a UIView inside something that might cause auto-layout to freak out.
Wow, thanks so much guys! I was having a huge problem with Xcode being slowed to a crawl while I was modifying interface elements in the interface editor. All I had to do was uncheck "Use Auto Layout" under the .xib's File Inspector tab, and it's running faster than ever!
So if you have any problems with Xcode's interface editor / Interface Builder being slow, just disable Auto Layout for that .xib while you're working on it, then when you're done editing the .xib, as a final step, re-enable it and add your constraints to the items.
I recently have been working on a project that has a xib file that contains a UIView w/ a UIScrollView inside of it. There is a long list of content within the UIScrollView, and I have noticed a significant decrease in speed while working in the Interface Builder.
All other files work fine and working with the Interface Builder with other files works perfectly. It is only this specific xib file that causes a lag of about 5 seconds after making even basic changes like clicking on a UILabel. I expect that the problem is caused by the amount of objects in the main UIView's UIScrollView.
I first tried restarting everything and then tried the suggestions from this thread: Xcode 4 - slow performance
None of them solved the issue. I have never had a similar problem before. Has anyone dealt with this kind of issue before and solved it?
I have a Late 2011 Macbook Pro w/ a 2.4GHz Intel Core i5 processor and 16GB of RAM.
While the .xib is in Interface Builder, go under the File Inspector tab and disable auto-layout for the .xib, then when you're done, re-enable auto-layout for the .xib and add constraints.
Also answered here: other stackoverflow question
For what's worth. I also had major performance issues with the new Xcode. Slow slower slowest.
I did 2 thing disabled indexing en forced stopped IB.
Disable indexing:
On the command line give the command:
defaults write com.apple.dt.XCode IDEIndexDisable 1
After this, Xode runs good. Although code completion etc will not work.
If you want you can turn it on again with:
defaults delete com.apple.dt.XCode IDEIndexDisable
Force stop of Interface Builder
I found this one by surprise. During one of those awfull moments when IB was doing something / nothing or whatever, I forced stopped Xcode.
Press Alt+Cmd
Select Xcode and press force stop
After that IB runned smoothly!
It is something related to auto layout. Not sure exactly what it is.
My problem was on particular xib.
When cancelling auto layout for that xib performance is smooth. As soon as I turn it on and put constraints on my scroll view (0 margins to all sides), it goes laggy again.
What solved the lags for me was to set navigation bar appearance in interface builder to none (Was opaque).
Strange thing is, it happens only on my Mac Book air 13'. My iMac runs this exact same file smoothly. Not sure if it has something with the hardware or not.
I am working on a mac osx control that is OpenGL based. Currently I am using an NSOpenGLView and a CVDisplayLink to coordinate my rendering on a background thread. This works great, but I need to allow Cocoa controls to be displayed over this OpenGL based control.
I realize you can do this with putting your Cocoa controls in borderless windows, however, that doesn't seem like a very good workflow for my users.
Alternatively I can make the view layer-backed and I got that working, however I don't like rendering my OpenGL content on the main thread, sometimes it blocks the main thread when the frame-rate dips.
Are there any samples that show how to achieve the best of both worlds?
The background thread for rendering is completely irrelevant. You just need to enable layer-backing for the views and then the subviews/controls will be composited correctly on top of your OpenGL content. You can also use CAOpenGLLayer for more explicit layering with CALayers.
I have a webapp for iPod touch and iPad. Works like a charm on iPad 1 and iPad 2. Now I have tested on a new iPad (iPad 3, iPad HD whatever name to be used) and I see that the painting of the screen is slow. I can see kind of blocks being painted one by one.
Anyone knows how I can get the painting of the screen faster than iPad 1 and 2 instead of slower ?
EDIT: Bounty expiry
The bounty has at least given some answers, although they are not sufficient to award the bounty. The question remains open.
We had similar problem in our application, and tried some optimizations, here are the two most effective approaches:
Avoid using CSS3 effects. We used a lot of CSS3 shadows in previous versions, which slowed down rendering process on iPad 3 a lot. After replacing those shadow effects with background images, performance got greatly improved on iPad 3.
Optimize Javascript. Our application has some scrollable components, whenever user scrolls the component some Javascript code will be executed to do some loading work, like loading images in a lazy way. On iPad 3 scrolling will delay for 500ms when user tries to scroll from one page to the next. Then we found some unnecessary image loading work were performed in the scrolling callback, after removing them, the scrolling performance is acceptable.
These two approaches may be quite specific to our application. Hope they can help you as well.
have you checked viewport in your meta?
I am using
<meta name=”viewport” content=”width=device-width, initial-scale=1, maximum-scale=1″>
I didn't feel any performance overhead. Perhaps some parts of your webapp hit on the weakness of web view.
You may start commenting your HTML until you find your webapp go smooth.
I have updated a New iPad (iPad 3) with iOS 6 and I do not see the rendering problem any-more. I have seen in several articles that the speed of Safari has significantly increased. This performance gain in iOS 6 is solving the problem for my web-app.
As the iPad's we use are dedicated for the web-app, I will recommend iPad 3 only with iOS6.
Thanks for the posts and answers !
I have OpenGL application with UITextField in the main menu. When I tap on the text field the keyboard appears and I can edit the text. But if I running under iOS 5 and if I try to split keyboard then the keyboard starts splitting (I mean animation) and then hangs when I release my fingers. I mean it hangs on half splitting - and does not responds more. But my app is still alive - and render is working well - background animation is still working.
I have just made a simple test - have disabled the render at all. And the problem has gone. So the problem is related to OpenGL.
I use OpenGL ES 1.1,
XCode 4.2 and iOS SDK 5.0.
Do somebody have similar problems? Any suggestions?
Please help.
UPDATE:
I have just tested two more games from AppStore - and in one I have found this problem too!
'Roads of Rome HD free' - iPad game.
I've encountered this problem too, but I was able to fix it due to previous experiences. In one application we found that if we keep our GL view active while playing video, the video playback position slider didn't behave smoothly. The same seems to happen with the keyboard split. If your problem is the same as mine, the issue is related to the keyboard split animation not finishing (and, in our case, the point where remained struck varied with each test)
We solved the issue stopping the animation on your GL view (I bet it's called EAGLView) when receiving a UIKeyboardWillChangeFrame notification and starting it again after UIKeyboardDidChangeFrame.
Old post, but I just came across this problem in ios 8 on an iPad3.
Running an OpenGL app at 60fps seems to throttle the keyboard update. Reducing your FPS while the keyboard overlay is active will fix the issue.
I'm using GLKViewController to manage the update and Draw callbacks with a 60fps refresh, but that was causing the keyboard split to lock up half completed.
I found the best solution for me was to set the view's preferredFramesPerSecond to 20 while receiving text input, and then set back to 60 after the textView is closed. As well as fixing the keyboard hang, it also just makes the keyboard generally more responsive.
myViewController.preferredFramesPerSecond = 20;