I have an XNA application that communicates with another process (on the same computer) using WCF.
On each Update cycle, the XNA will get data from the other process.
The XNA runs fine when in a window (over 60fps),
but if I try to run it fullscreen, I'm getting less than 1fps.
This does not happen if I turn off the WCF.
Why would fullscreen affect it like that ?
Any ideas ?
Thanks.
This seems like a long shot, providing that there's not much details, but it looks to me you have some thread starvation issues, possibly caused by page flip / buffer swap waiting for something? (What OS are you using, how many cores)
You should try using the profiler and analyzing the code to see where is the critical secion.
For a quick fix, try using Thread.Sleep(1), or switching to Async calls for your WCF service.
Related
I do understand that the first wcf call is usually very slow. And that is the case in my app. I have tried to apply various solutions I have found through out internet with very little progress.
But the thing that puzzles me is the fact that all subsequent wcf calls even after having exited and reentered the app after few minutes are very fast. Am I correct in thinking that android somehow keeps some dll or whatever resource related to wcf infrastructure in some memory cache so that even after reentering the app calls are fast ? If that is the case, can I use this same technique to keep "wcf resources" ready to fire for my app? (I hope my question is clear :-) Thank you in advance
I'm working on porting an app from iOS to WinRT/8 Metro/8 Immersive/Whatever the current name is.
On iOS, we have the ability to set Application does not run in background to YES to cause the app to actually quit whenever the user leaves the app.
I would like to figure out how to replicate this behavior in WinRT.
Yes, I understand that this is abnormal behavior.
Yes, I have thought this through.
Yes, I have an extremely good reason for doing this.
I'm assuming that during the userLeavingApp event, I would just call Application.Current.Exit(), but I can't seem to find the userLeavingApp event. I thought about using OnSuspending (Handles Me.Suspending) in App.xaml.vb, but that doesn't seem to be called quickly enough for me.
Is there a .NET equivalent of viewWillDisappear or something?
Any ideas? This is an important security characteristic of my app, and I'd hate to have such difficulty in an entire platform due to such a small issue.
Thanks!
I'm not actually seeing Application.Current.Exit() working in OnSuspending; although as you mention the suspending isn't happening fast enough for you (which is by design). Throwing an exception there didn't work for me either.
There is Window.VisibilityChanged and if I issue Exit/exception there, it does shutdown the app when another app takes over. That said, VisibilityChanged will fire under other circumstances too so not sure if you could cover all the scenarios or rely on them not changing. See here for a bit more context.
To echo #Filip, whose response just popped in, it's highly unlikely you'll pass certification. An Exit() call is tantamount to an exception.
I don't think your app will pass certification if you call Application.Current.Exit(). If you are really confident this is what you want - I guess it is worth a shot to try. You could though simply unload anything that uses memory/CPU when you exit.
I am getting a System.OutOfMemoryException from my vb.net application, it happened from one certain user. I am trying to figure out whether my application takes too much memory space or the PC has low memory. But she just upgraded her desktop as i3 Intel CPU and higher memory.
Is there any tool that I check memory consumption when code is executed as go through lines?
By the way, it is developed by vs2010 and It is a Windows application.
<--Edit-->
I found the problem from my application. I did not mention because I did not know what the problem was. I am using a Google map inside of vb.net application. It takes a memory whenever I search a map on web browser which is on a form . Even though I close the form, it is not disappeared from
memory. It is just going up. That goes away when I close MDI form. FYI..
The best tool we've worked so far is the JetBrains profiler (http://www.jetbrains.com/profiler/features/).
That's a common error. It normally happens when the application enters a loop that never ends... (infinite loop).
Is it a Console, WinForms, ASP, WPF?
Try to identify during which Event your application throws the exception and put a try catch to print out more details.
Just check out this cool WPF performance suite to check out if you have memory leaks:
Performance Toolkit
Or check out if you can use GC.Collect() to find the leak.
Also you can accecss in Process Explorer to any .Net memory data and peaks.
Regards
I have a college assignment due quite soon, and I need to be able to call a C++ dll that takes a long time (possibly infinte, it relies on user input)to execute. Im calling this through VB. My VB GUI freezes up when this happens, and I would like to keep the GUI responsive, so that the user can stop this possibly infinte loop.
Can anyone suggest the best/fastest way of doing this?
A bit of background, the C++ is trying to keep score on a snooker table using a webcam, and while the VB scoreboard updates easily, I would like to script it so that the analysis is almost continuous, while still allowing the user to interact. Currently the project requires the user to press a button to start the shot analysis, but it would be preferable if the program scripted itself. I have only realised this problem now and the deadline is very soon.
Update: Our lecturer suggested an option to solve the problem, but it would appear that most options here and the one he suggested will not work for us as the processing time required for the webcam image capture is too great to handle due to hardware constraints. Thanks for taking the time to help, it was much appreciated!
The best way to handle threading in VB.NET is via the System.Threading namespace.
You might also look into Application.DoEvents()
Try the system.Threading as Mark said, also try looking at Background Worker Process which is a bit simpler in VB.NET. Readup here
I would definitely use the Background Worker process. You can drag it onto your form and use the DoWork sub routine to actually do the work that is freezing your GUI thread. You can also use the ReportProgress event to actually provide progress back to your form.
As for your question regarding two separate threads, If both steps take a long time to complete I would run them in the same thread one after the other.
The one thing that could bite you with using the thread is cross-threading. In the context of your problem this means not having your second thread update form controls.
A really good resource for how to implement this code along with dealing with cross-threading is this PDF.
I also should point out that if you are using .net 1.0/1.1 you can still do the multi-threading, but don't have the luxary of having a background worker control. You'd just have to create a new thread from the System.Threading Namespace.
Just as an alternative, you could have your C++ actually processing in the background all the time. When called from VB, it would just be retrieving data from it or sending it a command (start, quit, ???) all of which would return instantly.
This could also give you more reliability since C++ would never miss video frames while VB was collecting the garbage or doing the dishes or whatever VB does in the background--C++ is going to let you be closer to a real time system.
RE: the comment about how.
What I'd probably do is have my VB programs send "Messages" to the C++ (As I said). A message is just a way to think of a function/method call--but generally they return quickly.
The "Start" message would tell the C++ code to start it's thread running and return. This is a Linux C++ thread howto, I'm not sure if you need to do something different in windows (I'd hope not, but I haven't used C++ as my main dev. language in decades).
If that doesn't work, just google "C++ Threads"
Sending a "Stop" message would stop the thread (and probably free resources).
A "Get Data" call would go to the location that the C++ thread used to store data, grab it and return.
Sorry to be so general, I'm pretty heavily Java these days.
I'm surprised nobody has suggested using a BackgroundWorker yet.
I've used the CF Remote Performance Monitor, however this seems to only track memory initialised in the managed world as opposed to the unmanaged world. Well, I can only presume this as the numbers listed in the profiler are way short of the maximum allowed (32mb on CE 5). Profiling a particular app with the RPM showed me that the total usage of all the caches only manages to get to about 12mb and then slowly shrinks as (I assume) something unmanaged starts to claim more memory.
The memory slider in System also shows that the device is very short on memory. If I kill the process the slider shows all the memory coming back. So it must (?) be this managed process that is swallowing the memory.
Is there any simple(ish?) fashion how one can track unmanaged memory usage in some way that might enable me to match it up with the corresponding P/Invoke calls?
EDIT: To all you re-taggers it isn't .NET, tagging the question like this confuses things. It's .NETCF / Compact Framework. I know they appear to be similar but they're different because .NET rocks whereas CF is basically just a wrapper around NotImplementedException.
Try enabling Interop logging.
Also, if you have access to the code of the native dll you are using, check this out: http://msdn.microsoft.com/en-us/netframework/bb630228.aspx
I've definitely been fighting with unmanaged issues in a C# managed app for a while -- it's not easy.
What I've found to be most helpful is to have a regular output to a text log file. For example you can print the output of GlobalMemoryStatus every couple of minutes along with logging every time you load a new form. From there you can at least see that either memory gradually erodes, or a huge chunks of memory disappeared at specific times of the day.
For us, we found a gradual memory loss all day as long as the device was being used. From there we eventually found that the barcode scanning device was being initialized for no particular reason in our Form base class (I blame the previous developer! :-)
Setting up this logging may be a small hassle, but for us it paid huge dividends in the long run especially with the device in live use we can get real data, instrumentation, stack traces from exceptions, etc.
Ok, I'm using C++ on CE, not C# so this may not be helpful, but...
I use a package called Entrk toolbox which monitors memory and resource usage, leaks, and exceptions under Windows CE. Pretty much like a lightweight CE version of boundschecker. Does the trick most times.