3 ms·

People are saying that wpf was good forgetting that ms has botched it from the start. First releases had god awful font rendering, that our (.net shop) enterpr

by galkk 4y ago

People are saying that wpf was good forgetting that ms has botched it from the start. First releases had god awful font rendering, that our (.net shop) enterprise customers hated. The things improved only when ms did some parts of visual studio in wpf, if I recall correctly. Also quite bad visual designer. (Even 2! Visual studio’s one and there was another software. Blend?)

jiggawatts 4y ago
Windows Presentation Foundation had some shocking quality issues that Microsoft outright refused to fix, arguing with customers in support forums that it was “like that by design”. It was. It was broken by design because it was designed for customers, not Microsoft themselves. It was designed to be just complete enough for the “demo” apps in the documentation, and no more. The most egregious example of this that made me give up on WPF entirely is how they implemented list control data virtualisation. Data virtualisation is when you have a list of 10K table rows and want to render only the 100 rows that’s visible on the screen. If a user scrolls through the list, there are only ever a few hundred GUI objects in existence. In WPF, this interface was an IEnumerable, which meant that the framework was forced to iterate through 9000 items to get to 9001. You could see this as you scrolled down a long list: at some point the FPS would drop and the CPU fans would spin up. The workaround for this required heroic efforts, something like several thousand lines of code. Meanwhile a simple C# WinForms app could scroll through 40K rows no sweat. Microsoft left this in WPF for years and years, telling customers that it’s “too hard” to change an established API. They fixed it the second they had to eat their own dog food when they needed WPF for Visual Studio. You see, the compilation error list can be very long and merely scrolling through it could bring a high-end gaming PC to its knees. I and many others in the industry decided to never write Windows GUI software ever again.
- vborovikov 4y ago
  The workaround was using a collection wrapper inherited from CollectionView class, usually ListCollectionView or CollectionViewSource. So you could create a collection view, bind it to the list control's ItemsSource property and that was enough. That's few additional lines of code in a view model.
- iecheruo 4y ago
  I don't know that that charactization is accurate. At a minimum you needed to implement an IList whos indexer creates the actual data when called. You would then set that IList on an ItemSource. If you could not provide data synchronously you could return an observable object and raised property changed events when the data was available I don't know if there were constraints that that unworkable for your scenario but my memory was data virtualization not being that much more code than WinForms. Visual Studio introduced an interface that formalized fetching a page at a time so you did less bookkeeping when mapping indices to items for SQL like scenarios but I don't know if controls had better performance using that interface
  - jiggawatts 4y ago
    This seems like it would work, but it actually didn't. One issue was that WPF uses rows with dynamic row heights instead of fixed row heights like GDI or WinForms. This forced it calculate everything it needed for the layout of each row to compute the total height, scroll position, etc... Like I said, this got changed when Visual Studio was rewritten to use WPF, and it "works now", but the default behaviour is still the slow path, not the fast path.
dh2022 4y ago
The designer was called Blend - it was started by a dev that, among many other things :), created the designer for WinForms. And the hacks they had to make in WPF to support any VisualStudio designer (WPF had to detect if it was running in designer mode and do things differently https://learn.microsoft.com/en-us/dotnet/api/system.componentmodel.designerproperties.getisindesignmode https://learn.microsoft.com/en-us/dotnet/api/system.componen...)

by galkk 4y ago

jiggawatts 4y ago

Windows Presentation Foundation had some shocking quality issues that Microsoft outright refused to fix, arguing with customers in support forums that it was “like that by design”. It was. It was broken by design because it was designed for customers, not Microsoft themselves. It was designed to be just complete enough for the “demo” apps in the documentation, and no more. The most egregious example of this that made me give up on WPF entirely is how they implemented list control data virtualisation. Data virtualisation is when you have a list of 10K table rows and want to render only the 100 rows that’s visible on the screen. If a user scrolls through the list, there are only ever a few hundred GUI objects in existence. In WPF, this interface was an IEnumerable, which meant that the framework was forced to iterate through 9000 items to get to 9001. You could see this as you scrolled down a long list: at some point the FPS would drop and the CPU fans would spin up. The workaround for this required heroic efforts, something like several thousand lines of code. Meanwhile a simple C# WinForms app could scroll through 40K rows no sweat. Microsoft left this in WPF for years and years, telling customers that it’s “too hard” to change an established API. They fixed it the second they had to eat their own dog food when they needed WPF for Visual Studio. You see, the compilation error list can be very long and merely scrolling through it could bring a high-end gaming PC to its knees. I and many others in the industry decided to never write Windows GUI software ever again.

vborovikov 4y ago
The workaround was using a collection wrapper inherited from CollectionView class, usually ListCollectionView or CollectionViewSource. So you could create a collection view, bind it to the list control's ItemsSource property and that was enough. That's few additional lines of code in a view model.
iecheruo 4y ago
I don't know that that charactization is accurate. At a minimum you needed to implement an IList whos indexer creates the actual data when called. You would then set that IList on an ItemSource. If you could not provide data synchronously you could return an observable object and raised property changed events when the data was available I don't know if there were constraints that that unworkable for your scenario but my memory was data virtualization not being that much more code than WinForms. Visual Studio introduced an interface that formalized fetching a page at a time so you did less bookkeeping when mapping indices to items for SQL like scenarios but I don't know if controls had better performance using that interface
- jiggawatts 4y ago
  This seems like it would work, but it actually didn't. One issue was that WPF uses rows with dynamic row heights instead of fixed row heights like GDI or WinForms. This forced it calculate everything it needed for the layout of each row to compute the total height, scroll position, etc... Like I said, this got changed when Visual Studio was rewritten to use WPF, and it "works now", but the default behaviour is still the slow path, not the fast path.

dh2022 4y ago

The designer was called Blend - it was started by a dev that, among many other things :), created the designer for WinForms. And the hacks they had to make in WPF to support any VisualStudio designer (WPF had to detect if it was running in designer mode and do things differently https://learn.microsoft.com/en-us/dotnet/api/system.componentmodel.designerproperties.getisindesignmode https://learn.microsoft.com/en-us/dotnet/api/system.componen...)