Leopard 10.5.8, XCode 3.1.1; using runModalForWindow to implement (what is intended to be) a high performance mouse tracking mechanism where I have to do real-time complex bitmap modifications.
The modal loop runs, the timer fires, the mouse tracks... but the performance is abysmal, and it gets worse and worse the longer the runloop goes on. Instead of catching mouse messages every pixel or so, I get them every 5... 10.... 20 seconds.
Instruments shows that the majority of the time during this growing response bottleneck is being spent in mach_msg_trap (and yes, I have the perspective set to the running app), so the impression I am under is that it "thinks" it doesn't have any work to do, despite the fact that I'm dragging the mouse around with the button held down like a crazy person. There are no memory leaks showing up, and in my 8-core 2.8 GHZ machine, there's almost no CPU activity going on.
Again, the app is not spending much time in my code... so it's not a performance problem of mine. I've probably configured something wrong, or failed to configure it at all, or am simply approaching the whole idea wrong -- but I sure would appreciate some insight here. As it stands now, the dispatch of mouse messages and timer messages is absolutely unacceptable. You couldn't implement a crayon drawing program for someone immersed in cold molasses with the response times I'm getting.
EDIT: Some additional info: doesn't happen on my 10.5.8 macbook pro. Just the 8--core, 6-display Mac Pro. I tried taking the display code for the croprect in drawrect out, replaced it with an NSLog()... still drags on issuing mouse updates. Also tried rebooting and running without the usual complement of apps running. And with mirrored displays. No difference.
Imagine dragging a brush across the screen; at first, is paints smoothly, then gaps appear between brush placements, then they get larger, and this goes on until you're only getting one brush placement every 10 seconds. That's how this acts. Using NSlog() and various other tracking methods, I've determined that it is at least at the highest level occurring because the mouseDragged events slow down to a trickle. The question in a nutshell is, why would that happen?
Anyone?
OK, isolated it -- the problem comes from my Wacom Tablet mouse. Plug in a regular optical mouse, and everything runs great. Same thing on my Macbook pro, using the trackpad. Works fine.
The tablet is a Wacom Intuos 4 with the stock drivers as of January 2011. I'm going over to the Wacom site and reporting this next.
What a nightmare that was. I have spent over 100 hours on this, thinking I'd hosed some subtlety in the app handling, drawing, etc. Sheesh.
Related
I am creating an application for Mac, in Objective C, which will run in the Menu-bar and do periodic Desktop operations (such as changing the wallpaper). I am creating the application so that it stays in the Menu bar at all times, allowing easy access to configuration options and other information. My main concern is how to schedule my app to run every X minutes to do the desktop operations.
The most common solution I have seen is using NSTimer, however, I am concerned that it will not be memory efficient (after reading the following page on Apple Developer docs. Using an NSTimer will prevent the laptop from going to sleep, and will need an always-running thread to check for when the NSTimer has elapsed. Is there a more memory-efficient way of using NSTimer to schedule these operations?
Alternately, is there a way to use LaunchD to initiate a call to my application (which is in the Menu bar) so that it can handle the event and do the desktop operations. I think that the second way is better, but am not sure if it is possible.
First, excellent instincts on keeping this low-impact. But you're probably over-worried in this particular case.
When they say "waking the system from an idle state" they don't mean system-level "sleep" where the screen goes black. They mean idle state. The CPU can take little mini-naps for fractions of a second when there isn't work that immediately needs to be done. This can dramatically reduce power requirements, even while the system is technically "awake."
The problem with having lots of timers flying around isn't so much their frequencies as their tolerances. Say one you have 10 timers with a 1 second frequency, but they're offset from each other by 100ms (just by chance of what time it was when they happened to start). That means the longest possible "gap" is 100ms. But if they were configured at 1 second with a 0.9 second tolerance (i.e. between 1s and 1.9s), then the system could schedule them all together, do a bunch of work, and spend most of the second idle. That's much better for power.
To be a good timer citizen, you should first set your timer at the interval you really want to do work. If it is common for your timer to fire, but all you do is check some condition and reschedule the timer, then you're wasting power. (Sounds like you already have this in hand.) And the second thing you should do is set a reasonable tolerance. The default is 0 which is a very small tolerance (it's not actually "0 tolerance," but it's very small compared to a minutes). For your kind of problem, I'd probably use a tolerance of at least 1s.
I highly recommend the Energy Best Practices talk from WWDC 2013. You may also be interested in the later Writing Energy Efficient Code sessions from 2014 and Achieving All-day Battery Life from 2015.
It is possible of course to do with with launchd, but it adds a lot of complexity, especially on installation. I don't recommend it for the problem you're describing.
I recently I came across an error that I cannot understand. The game I'm developing using Cocos2D just freezes at a certain random point -- it gets a SIGSTOP -- and I cannot find the reason. What tool can I use (and how do I use it) to find out where the error occurs and what's causing it?
Jeremy's suggestion to stop in the debugger is a good one.
There's a really quick way to investigate a freeze (or any performance issue), especially when it's not easy to reproduce. You have to have a terminal handy (so you'll need to be running in the iOS simulator or on Mac OS X, not on an iOS device).
When the hang occurs pop over to a terminal and run:
sample YourProgramName
(If there are spaces in your program name wrap that in quotes like sample "My Awesome Game".) The output of sample is a log showing where your program is spending time, and if your program is actually hung, it will be pretty obvious which functions are stuck.
I disagree with Aaron Golden's answer above as running on a device is extremely useful in order to have a real-case scenario of where the app freezes. The simulator has more memory and does not reproduce the hardware of the device in an accurate way (for example, the frame rate is in certain cases lower).
"Obviously", you need to connect your device (with a developer profile) on Xcode and look at the console terminal to look for traces that user #AaronGolden suggested.
If those are not enough you might want to enable a general exception breakpoint in Xcode to capture more of the stacktrace messages.
When I started learning Cocos2D my app often frooze. This is a list of common causes:
I wasn't using sprite sheets and hence the frame rate was dropping drammatically
I was using too much memory (too many high-definition sprites. Have a look at TexturePacker and use pvr.ccz or pvr.gz format; it cuts memory allocation in half)
Use instruments to profile your app for memory warnings (for example, look at allocation instruments and look for memory warnings).
My friend is currently making a game in gamemaker, but whenever I test it out for him my computer seems to just completely lock up. My PC that I am testing on is no way underpowered, it has a 2500k, Radeon 6950 and 8GB RAM. My RAM, GPU and CPU usage is barely touched during the freeze. If I am playing music at the time of the freeze the speakers just buzz. Whenever is occurs a full system reboot is always required, nothing at all responds. The image of the game stays on the screen, mouse, keyboard and restart button don't respond. This question may be better suited for the Gamemaker forums, but it could be an issue with my computer. I am unsure. I can play MW2 and Crysis for hours without it crashing, so it is either a software problem or something weird. All of my temps are normal. Others have suggested checking while loops, but wouldn't an infinite loop cause the CPU usage to rise?
In any of your loops that have a potential of running infinitely, put io_handle(); (I think thats the command) This command somehow keeps windows from thinking a program has frozen. If that isn't the case... then try to play the music through an extension like fMod or another one. Furthermore, try it on another computer is it just your computer? Your computer doesn't sound underpowered at all... but what about your operating system? If you're using xp it may not support the Directx that GM requires. I believe that its very easy to make gm games very directx intensive, so check that out. Good luck! I love Game Maker!
It's most likely an infinite loop in your code. Try stripping away your code, compile, and test if your computer freezes again. Then build back up to where you started from.
This kind of issue is probably due to something internally in game maker, OR it could be an issue with a listener or script you may have bound to a sprite or object. Begin removing things, one by one, until you find the culprit.
Try to strip out pieces of code part by part and isolate the function / code that is causing the freeze. Then come back here and tell us the status.
I've kind of seen this before on another Gamemaker game. Do you have any infinite loops or shaders in your game? The last game that had this problem was caused by a bad shader.
Why does NSColorPanel accumulate memory usage? Try it:
Create a brand new cocoa-based application in Xcode
add a sinlge NSColorWell to the main window
Run app and open a memory monitor (ex. Activity Monitor)
Click the colour well to bring up the NSColourPanel
Click and drag your mouse on the colour wheel, twirling it around and around for a while, watching the app's memory usage
Result: Memory keeps climbing, slowly but surely (4-5Mb's in about a minute). In my tests, it seems to hit some sort of barrier after climbing about 4 megs, after which it stays somewhat steady, or climbs more slowly. And this is with garbage collection turned on. With it turned off, there seems to be no barrier; memory usage keeps climbing steadily.
This isn't a huge deal, practically-speaking. But it bothers me. I want to know what is going on with the memory, if such "leaks" (?) occur in other standard gui objects the developer may have no fine control over, and if this is just a gap in my understanding of how things work.
The only thing I can think of is perhaps the app is storing a history of selected colours for whatever reason (and this history keeps growing), but this seems unlikely to me.
File it at bugreport.apple.com.
Hey, im running cocos2d, box2d and several particle systems on the iPhone 4.
I've completed my first level which has numerous sprites allocated as well.
I have set my FPS limit to 30fps.
When the game first runs, it runs well, at a solid 30fps. This continues for about 3-4 minutes of smooth gameplay.
But after a while the fps starts to drop, and it turns into a gradual decline until it hits around the 12fps mark.
I remember I had this problem with a previous game that I abandoned.
Is this caused by a memory leak, possibly from not deallocating items??
In my (void)dealloc methods, I am inputting all my allocated releases, could I have missed one? Or is there some other possibility i'm not considering?
Thanks!
Sounds like you're running out of resources. I'd try Instruments as suggested by SB. Instruments can check for leaks using the Allocation instrument. You could also try the OpenGL profiling suite.
I have the same problem and I cannot get the resolution. When I unload the entire scene and reload it again, everything is back to normal. So it definitely seems to be a leak somewhere, but even with instruments I cannot find the source of it.
The total memory usage is not growing, no leaks reported, so I have the feeling that something in Cocos2d or in Chipmunk increasing the load.
I am using sprites which are moving in and out from the screen in a random manner and creating nd destroying them every time. Can it be that something is not released properly and Cocos or Chipmunk is still calculating with those items?