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.
Related
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.
I am trying to make a text reader, but I found that when scrolling a large document, at some point whenever the texture memory reaches around 15000 the app just exits with code -2147220978 (0x8004020e).
What does it mean? Is there any work around? I really need to be able to read large text documents.
The 8 means "error". The "004" means "this error is specific to the interface that the object was using at the time it failed". The "020e" means... well, it means whatever the author of that interface intended it to mean. (All error codes above 0200 are author-defined.)
These are the hardest errors to track down because their meaning is entirely dependent on what the author of the code that failed intended; there is no universal standard. Some subsystem, perhaps developed by a third party, is failing. If you can figure out what subsystem that is, then you can ask the makers of that subsystem what their error number 020e means.
Can you share minimal and relevant repro code? Just one snippet of XAML And one snippet of C# should be enough.
From what you're saying it really might be overloading the GPU with surfaces until the app crashes. It shouldn't ever happen, so I'm not sure this is the real cause.
In the meanwhile, have you tried virtualizng your ItemsControl? If you're using a ListBox have you tried switching to the new LongListSelector? If just switching to LongListSelector isn't enough, try using ItemRealized and add some prefetching logic. If that doesn't work, you might have to create your own virtualizing logic either by manaully removing the Template from the visual tree once it goes out of view or creating a whole new 3rd party virtualized custom control. Maybe one of the 3rd party control vendors has something that would work here.
I'm doing some performance minded work on an existing winforms project.
This form is made dynamically rather than at design time, and loads a few dozen user controls, as well as binding them to a DataSet object with a small set of data.
Using some profiling tools (ANTS, Avicode), i can see most of time, around 50%, is taken by the code i have to show a tab page i have on the form. drilling down, i see it divides roughly in half to two operations:
1) a long line of VisibleChanged/SetVisibility/SetVisibleCore operations, all in the winforms namespaces. How can i know if the time it takes (4.5 seconds in my case) is sane? I do have a lot of user controls in my form.
2) A long line of RightToLeftChanged operations, again, around 4.5 seconds. Here too, I'm wondering if this is expected/sane performance of WinForms.
any advice regarding finding the performance issues here or whether the performance i'm getting is normal would go a long way to help. Thanks in advance :)
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)