I have a problem with slow UWP performance. I know that this topic was discussed a lot of times, but everything is from 2017 or older, and nothing was useful for me. In short, the more times I change application's pages, the more lagging I have.
I tried all combinations: disabling and enabling option Compile with .NET Native tool chain, switching between Debug and Release mode, I wrote application native way and in Xamarin.Forms (Android works good what's interesting) but every time I had problem with UWP. The method I use to going to other page:
this.Frame.Navigate(typeof(Page2));
So my question is, if anyone solved problem with lagging, or is maybe other method for switching pages?
Finally I found the solution. In my case the problem was in handling my UserControl toolbar - too often refreshing data. I added longer Task.Delay to my infinite loop that was refreshing data on toolbar and now everything works fine.
Related
I started converting a WinForms application of mine over to WPF, and there was one major issue I noticed right off the bat: even on a completely blank WPF project, the application will take roughly a second to open, whereas even heavy/intense WinForms applications I've written start up instantly or with no noticeable delay. Is this a global issue, or is it just me? If the former, is there any way to circumvent this? I find it incredibly annoying.
I apologise if this is a duplicate question (since it seems like something really basic), but I can't find any information on this.
I'm now working on some pretty big application with really nasty code. The problem is that from time to time the whole GUI of the app is freezing and stops responding (and after some time Windows wants to take the app down). I have a really big problem to even look where to debug the app, mostly because when this thing happens and I pause it in the VS debugger, it highlight the line:
CardWindow.ShowDialog();
It's not helpfull at all. Also when this thing happens it tends to grow the app size in the memory, ocasionally throwing OutOfMemoryException.
I also checked whether it might be some kind of an infinite loop in one of created threads, but VS shows me that only the main thread is active, and the rest are either ended or not running at all (the thread implememtation is also really poorly written).
The application uses remote objects within local networks, and some threads are used to transfer photos and other data from clients to server, but I don't know how to check if this is what it's causing it. But when the server app hangs, the clients are still fully capable to connect with it.
Short info of how it's made: the app uses Firebird engine to store its data. The DB is on the server machine, and the clients are connected via local LAN to it using standard Firebird C# library, and the app instances communicates with each other using remote object (the server is also a client).
It's the second week of debugging and I'm getting pretty desperate as I'm getting out of ideas of even how to check what's wrong. The fact that the bug appears randomly also doesn't help.
Can anyone give me some ideas of how to find a trace of this bug?
Using C# .NET 4.5 and WPF with Visual Studio Ultimate 2013 and Firebird 2.5
I'd suggest using a profiling tool to assist in finding the problem
What Are Some Good .NET Profilers?
In addition to #DerekTomes. The System.Windows.ShowDialog method, Described in: Window.ShowDialog Method, all other windows are disabled and return only when the window is closed. Check to make sure the window is eventually closed(this.Close() in the CardWindow.xaml.cs or whatever .cs file) or use CardWindow.Show() instead of CardWindow.ShowDialog() so other windows remain running while the CardWindow is running.
I finally figured it out.
When the function that usually hanged the app after 30th run launched, I could see that some of it ran (the window's title changed as it was supposed to). I've found this function and after every single line put:
this.Title = "1";
SomeFunction();
this.Title = "2";
AnotherFunction();
this.Title = "3";
// and so on
I localized what was causing the problem; there was a function that changed the GUI significantly (lots of foo.Visibility and foo.Opacity) and ran in some weird loop. It was fine for the first 20 times to run it, but after 30th it slowed down the app, and after 40th - caused crash.
It now runs only once when it needs to and the problem does not appear. I suppose it caused GUI memory overflow of some kind.
Anyway, thank you for your answers - I ran memory profiling, but it slowed my app down to that point it was impossible to use it.
I have a very odd problem. I've written a little inhouse app which scrapes a load of URLs, performs HEAD requests to get the size and populate a ListView control. Everything works fine when I am running it inside Visual Studio when debugging, but when I deploy the listview does not populate. The 2 are making exactly the same calls consistently. Does anyone have any idea what may cause this to happen?
Thanks I was able to find the solution by attaching the debugger to the process... many thanks to all for answering. I know this is a trivial question...
Many thanks
JT
I wasn't sure how to write topic correctly but lemme describe what problem I have. On my old laptop when i was jumping between code and big WinForm GUI it took sometimes a lot of time before i could even do things within designer. Today I've changed my laptop to newer one and it still has some delays when "redrawing/rebuilding" winform gui.
Is there a way to prevent it to do that? I mean nothing in GUI changes so why would it need to redraw the gui again and again :/
Unfortunately no it is not possible to stop this behavior.
Before leaving the code view and going to the design view, save and do a build (F6). Often enough (but not always) the design view will not be redrawn.
I have a piece of software that has worked fine on many machines, althoughon one machine there is a problem that appears to occur occasionaly, the MenuStrip and the ToolStrip both appear as a blank white background with a red cross over it, as a custom control would if you created a null object. This doesn't happen whilst I am debugging and I don't know how to make the problem re-occur, but it does happen. I was wondering if anyone knew what could be the problem?
Would it be the version of the .NET framework?
Thanks
This is a common occurrence when there's a GDI+ problem ("The Red X of Death"). Are you doing any custom drawing in OnPaint? Or perhaps there's a graphic resource or a glyph which is corrupt or being improperly disposed of.
Edit: I've re-read your question. You seem to have this only on one of the machines. I've googled around a bit for this, and I stumbled upon this old thread. The post at the bottom suggests that there might be an issue with Virtual Memory turned off:
We did manage to solve this - we were
seeing the problem on a device running
XP embedded. The XPe image developer
had turned off Virtual Memory and as
soon as we turned it on the problem
went away. I believe it is just a
symptom of the system running out of
memory to display the graphics (maybe
particularly if you use a lot of
double buffering)
Hope that helps.
Sounds like a symptom of an Out Of Memory Exception to me.
Edit:
Which can sometimes lead onto a System.InvalidOperationException: BufferedGraphicsContext
Are you trying to update the GUI controls from a thread other than the GUI thread? Combine the cross thread operation with an exception handler that swallowed everything and we had the behavior you describe (on a grid control, not a menustrip bar) on an app I was maintaining.
Definitively sounds like a cross-thread problem.
Make sure you use Invoke when accessing controls and/or firing events from a thread that is not the main UI thread.
Seeing this happen on just one computer of more than a 1000 that have our prouducts.
On that one computer I am seeing a .NET 3.5 program occassionally show the red X on its datagrid. And another far simpler .NET 2.0 program got the red X on its menuStrip. I only have source code for the simpler program but I can say that there isn't any user code at all which affects that component. No cross-thread stuff because nothing updates it. It's contents are set at development time with one item added to it at program load. The Red X failure was well after program load.
I was very surprised to see the problem across two different frameworks and on one program that has no data bindings. I am very wishfully hoping that the computer has its virtual memory turned off.
If it isn't that then any guidance on system parts that are shared across .NET 2.0 and .NET 3.5 would be appreciated.
Update: The user with the problem retired the computer and replaced it (which solved the problem)