Sometimes, when I launch my game in LibGDX (the game doesn't require much power) the rendering is very laggy, but most of the time, when I run it the game runs smooth perfectly.
I would understand this if it would be laggy all the time, but it's laggy only in about 10% of the times when I run it. When I close it and run it again, it runs perfectly. Why is this happening?
I use Eclipse for launching and it runs as a desktop app.
I had the same problem. Try running it alone without Eclipse and it should work.
I experience this a lot it's not because of your libGdx project it's because of your computer. Computers just lag from time to time because of the multiple data or information they are handling everytime you're using it. Just ignore it man the important thing is you're making an awesome project, just don't mind the lag.
If you have a dual monitor setup, can you ensure there's no GPU activity on the other display? I noticed even with a decent setup, if something else was on my opposite monitor (eg., a chat client or a browser window) projects would run at a significantly slower framerate.
Related
I got a Colab Pro+ because I wanted to use the background execution option.
I enabled the background execution and GPU type and started my code.
My code is a simple CNN on Tiny ImageNet, which requires several hours of training on a GPU.
I closed the browser, and after one-two hours, I returned, and everything was frozen!
How can I resolve this issue?
This happens to me as well and the best solution I've been able to come up with (which works inconsistently, but seems to help a lot more that otherwise) is to prevent my screen from locking. Let me explain.
I run Colab Pro+ on a Macbook laptop, and the battery-saving settings are ordinarily such that the screen locks when the laptop is idle for 5 mins, the lockscreen comes up. I noticed that for some reason Colab was much more likely to freeze and disconnect if I was away from the laptop than if I were working on it for hours as it ran, so to superficially mimic this, I changed my settings to never lock the screen. And I then I realized that with these settings Colab would freeze and disconnect much less frequently, and I could successfully let it run overnight and check it in the morning. [Edit: let me clarify that I have not tried this while closing the browser. So I can attest to the efficacy of my method if you leave the browser open].
I have to say though, that it's been bad for my laptop and it's unacceptable that this is necessary despite what we pay for Colab Pro+. Their product simply does not work as advertised and we have no recourse. If anyone has discovered a better solution (that works) I'm all ears.
An alternative that works for me is to make the navigator click with some interval. You can add the following script to the console. It works well with Colab Pro and Pro+ but remember that, if you use the free account, Colab will disconnect you after some hours.
To open the console press F12 or ctrl/command+shift+i.
function Clicking(){
console.log("Clicking");
document.querySelector("colab-connect-button").click()
}
setInterval(Clicking,50000)
My macbook started freezing recently and I thought it might be due to shortage of memory. So I opened the activity monitor for the first time and I noticed there are some weird things happening with Chrome. Why are there so many Google Chrome Helper processes??
Is there any reason why there as so many processes?
Many thanks for your help
Well, for one, each tab of Chrome runs independently. So you'll see quite a few processes running due to that.
Another thing to keep in mind is extensions. Each of them usually run in their own process as well. If you have a lot of extensions running, they add up rather quickly.
I'm developing a WP8.1 SL app which uses background tasks (not agents!).
My task is triggered by a TimerTrigger - once every 30 minutes (which I believe is the minimum interval for Windows Phone, right?). It is doing a lot of work, and for some reason, sometimes it gets interrupted - that is, it stops in the middle of it. The way I know it's in the middle of it is because I log what's happening and the task's work is basically the same every time.
I deployed the app to my device yesterday to test a new approach, and everything was working fine - the background task was doing everything every time it was started - worked like a charm. Today my device needed a soft reset, so I did it (nothing was working, it happens from time to time since I updated to WP8.1). Since that moment, the background task gets interrupted every time, right in the middle of it, just as with the previous approach.
Any ideas what can cause this? I'm thinking it may be connected to the soft reset, because - 100% success rate before it, 0% after that.
What I've tried so far:
I'm logging errors, I have a try-catch around everything, I've subscribed to the UnobservedException event and to the task's Canceled event, and I'm logging the suspension count - none of these things help. There seem to be no errors, it's not suspended, and it's not canceled.
I'm logging the current memory usage from time to time, and it's about 16-17MB. On my device, the limit should be 30MB, so I don't think that's a problem.
I'm calling RequestAccessAsync wherever I can. I thought once should be enough, but since that soft-reset issue, i decided to put it in 1-2 other places to check if it's causing the issue. Well, it's not, or at least this didn't fix it.
What I'm not sure about:
I have no idea how to check the CPU time my task has consumed. I can't find a good/reliable way to do so. Also, I can't find any info that would explain why the task would be stopped in the middle sometimes, and other times - it would work fine.
Any ideas why my background task is sometimes stopped at the middle? I'm really having a hard time determining how to fix/improve the app and will it work at all.
Thanks.
So, I think I found what my problem was.
First of all, the background task just needed a lot of CPU time, more than the limit, and that's why it was getting killed in the middle.
The reason why it was working sometimes, was because sometimes the device on which I was testing treated the app as being in debug (or with attached debugger). In this case the restriction on CPU time is removed.
So, even if I uninstall the app and rebuild it in Release and redeploy, and start it without the debugger attached, the device was NOT enforcing the constraints. That only happens, if I have started the app with the debugger at least once (or maybe the first time) after it's deployed. Restarting the device (just power off and then turn on) fixes this.
While I was testing, using the same build of an app, its background task ran for 40 MINUTES on one device, and just 3-4 seconds on another. After I restarted the first device, the background task started behaving normally (running for just a few seconds).
So, if you want to test your background task for the CPU constraint:
You must be testing on a device, not on the Emulator.
Uninstall the app, if it's installed.
Restart the device.
Deploy a Release build of the app.
Run the app, so that it can register the background task, and then close it.
Wait for the background task to be invoked. (You could add a trigger that can be forced, like TimeZoneChanged or UserPresent, so that you could quickly test it.)
P.S. This may not be the perfect answer, but these are my observations, and they helped me solve my problem. This by far is the best method I have found for testing the CPU time, and it's far from perfect. So, if anyone has better ideas, please share them.
We have an air application (native for windows) that after being unused or background for about some hours after you try to use it it got stuck and "not responding" windows message.
No log or error or crash just got stuck.
The best behaviour that we have got is that after some seconds it unstucks but then stucks and unstucks every 30 seconds aprox, so it is anusable.
We have tried some "ugly" tricks like after being out of focus/background for some minutes, goes into front, it goes, but this haven't resolved the above problems.
I understand clearly, that SO (Windows) has removed the cached memory pages associated to this process, however, this is normal for each program, so, it is normal that program (specially visually heavy like ours) come back to use, it takes some seconds to go into memory again.
However after that time of re caching into memory any programs (most) works like a charm.
This is not the case of air app.
is there any trick or recommendation for fixing this?
Maybe we should combine the "to front" trick with some other "dumb processing" to keep the program in memory?
thanks in advance.
My app is like a tweet feed reader. But with use, the app's responsiveness slows down in the wp8 emulator. By being unresponsive, I mean the progress bar indicator speed slows down, no links respond, none of the app buttons respond and the app suddenly closes.
I think it is a memory issue with the emulator. Am I right? I can't test it as I don't have a device yet.
Even on increasing the memory using the Hyper-V settings I didn't observe much difference.
I have an in-app browser which works fine for the first 2-3 links but then makes the app hang!
This doesn't sound like a memory leak. What you're describing is a slow-down which is caused by putting too much work on the UI thread. Overall you should offload as much work as possible to a background thread or the compositor thread.
The app suddenly closes sounds like some unhandled exception, but it's hard to tell which one. You said the app works fine on WP7. Have you looked at known app compatability issues that occur once WP7 apps are upgraded to WP8? Check it out on MSDN # http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206947(v=vs.105).aspx
This really isn't enough to go on. Is there something printed out in the output window once the app crashes? Can you tell what's the last managed method to be invoked before the app crashes? Can you try profiling the app for CPU and see what's the method that's most invoked? And profile for memory usage and see how's memory consumption right before the crash?