3 ms·

> The one and only problem with winforms I encountered is its bad performance. Can you elaborate on that? If you keep the work off your main thread, and don't

• Const-me 8y ago
  Not OP but I too encountered performance issues with WinForms. When you have long lists, or any large content inside scrolling panels, you’re technically creating an enormous amount of controls, and the performance degrades. Possible to workaround, e.g. lists have ListView.VirtualMode property + associated events, for long web page-like content you can use an embedded browser, etc., but these workaround tend to be quite tricky to implement and debug. WPF too has a couple of issues with UI virtualization, but by comparison, it’s much simpler in WPF than in WinForms.
• Traubenfuchs 8y ago
  > main thread I tend to give every custom "singleton" window its own thread -you don't have to limit yourself to one main thread and I dislike modal interactions. Performance in that sense was great and taking care to correctly use Invoke/BeginInvoke made hassle free multithreading a breeze. > and don't create an enormous amount of controls That's exactly what I did. I created so many controls, the application rendered white boxes with a red strikethrough or outright crashed. WPF does not have that problem and additionally offers virtualization to speed up visual containers containing lots of complex controls/children. Yet WPF is a complex, overengineered mess with a steep learning curve. It was my first big project to write a desktop application -I used winforms for it and everyone loved it. It was a tiny .exe file. I tried rewriting it in WPF three times but gave up every time...