upvote

points

by mwcampbell20 hours ago |
comments
upvoteby fsloth13 hours ago|
next
[-]
"WPF had made a bet on then-advanced graphics hardware for reasonable performance, and that was bad for these users. "

OTOH WPF is today surprisingly strong GUI platform if you just want to get your Windows GUI out there.

It runs really nicely even on low end hardware. All the nice styling and blending techniques now _just work_ even on the most cheap low end laptop.

The fact it's over decade old means all the LLM:s actually know really well how to use it.

So you can just guide your LLM to follow Microsoft best practices on logic development and styling and "just add this button here, this button here, add this styling here" etc.

It's the least annoying GUI development experience I've ever had (as a dev, non-designer).

Of course not portable out of the box (avalonia is then the ticket there).

If you want 3D, you can just plug in OpenTK with OpenGL 3.3. Decades old _but good enough for almost everything_ if you are not writing a high perf game.

Really, WPF plus OpenTK is a really robust and non-surprising development platform that runs from old laptops (eg. T14 Gen 2 per my testing) onwards.

I've been doing a sideproject using WPF and OpenTK - .net works really great - here is a sample video of the whole stack (from adashape.com)

https://youtu.be/FM_iuB3-0aA?si=j7kS68ZVenmPwvAO&t=34

reply
upvoteby fleventynine17 hours ago|
prev|
next
[-]
I had the misfortune of writing a complicated WPF app from scratch circa 2010-2011. Performance using the WPF widgets was terrible compared to HTML/Javascript/Blink; we ended throwing away most of the WPF code other than the main shell and a few dialogs, reimplementing the importantant stuff with immediate-mode Direct3D/Direct2D to get the necessary speed.

I recall wasting a lot of time staring at decompiled .NET bytecode trying to understand how to work around many problems with it, and it was clear from the decompiler output that WPF's architecture was awful...

reply
upvoteby n8cpdx18 hours ago|
prev|
next
[-]
It goes back pretty far. Nowadays the controversy is electron vs native (where most windows devs would consider WPF/.NET a native option).

But if you read books from the 2000s, there was much discussion about the performance overhead of a VM and garbage collected language; something like WinForms was considered the bloated lazy option.

I’m sure in a few years computers will catch up (IMO they did a while ago actually) and Electron will be normal and some new alternative will be the the bloated option - maybe LLMs generating the UI on the fly à la the abomination Google was showing off recently?

FWIW Apple has made a similar transition recently from the relatively efficient AppKit/UIKit to the bloated dog that is SwiftUI.

reply
upvoteby pipeline_peak17 hours ago|
parent|
[-]
What have you heard about SwiftUI being bloated?
reply
upvoteby n8cpdx14 hours ago|
parent|
[-]
My lived experience. Maybe bloated isn’t the right word, but attention to performance just isn’t there. Try using any swift UI app on iPhone or Mac. Try resizing a swift UI app window on Mac.
reply
upvoteby jshier7 hours ago|
parent|
next
[-]
Yeah, it's not bloated, there are just a lot of surprising and weird performance holes, especially on macOS. Even on iOS there's dumb things like, if your List cell's outer view isn't a specific type, List won't optimize for cell reuse, and it will start dequeuing cells for every item in the List eagerly. Wrap your actual cell type with a VStack or something and it will work properly, only dequeuing visible cells. It can be really nice to work with, but man, some of the implicit behavior, performance other otherwise, is shocking.
reply
upvoteby hypersolo7 hours ago|
parent|
prev|
[-]
[dead]
reply
upvoteby rincebrain19 hours ago|
prev|
next
[-]
I would argue that was less that WPF was the wrong life choice and more that Microsoft shouldn't have bent the knee to Intel's antitrust push to say their crap hardware was sufficient. [1]

[1] - https://arstechnica.com/gadgets/2008/03/the-vista-capable-de...

reply
upvoteby mwcampbell11 hours ago|
parent|
next
[-]
Your argument presupposes that we should accept escalating baseline hardware requirements as good or even necessary, for a desktop computing world that was, from the user's perspective, doing pretty much the same thing as before. I reject that.
reply
upvoteby rincebrain23 minutes ago|
parent|
[-]
My recollection of current events at the time was that you were already having a dogshit experience using computers for many common things in the XP era with underpowered video hardware and trying anything complex in a browser, or Flash things with a lot of assets, so it's less forcing escalating a baseline and more recognizing the realities of what people were already expecting in a "good" computer and building thing that could take advantage of that.

I would agree it should have degraded much more gracefully and more readily than it did, but I'm quite confident we hadn't hit the point of minimal returns on improvements in hardware that would be necessary for such an argument yet.

Hell, I probably wouldn't make that argument until large amounts of RAM and VRAM (or unified RAM) are ubiquitous, because so many workloads degrade so badly with too little of either.

reply
upvoteby bombcar18 hours ago|
parent|
prev|
[-]
Apple had been doing GPU-accelerated GUIs since the early NeXT days; it was certainly possible on hardware weaker than what Vista required.
reply
upvoteby runjake18 hours ago|
parent|
next
[-]
Minor correction: Apple introduced GPU-accelerated GUI in 10.2 with the introduction of Quartz Extreme.

Display PostScript did not have GPU acceleration, as far as I know.

https://en.wikipedia.org/wiki/Quartz_Compositor?#Quartz_Extr...

reply
upvoteby Zardoz8416 hours ago|
parent|
prev|
next
[-]
Windows 3.1, with the aproppiated drivers and modern SVGA card, had accelerated 2d graphics. Accelerated GUIs don't even need GPU or 3d.
reply
upvoteby ShroudedNight11 hours ago|
parent|
[-]
What does "GPU" mean here? Previous uses of the term seemed to imply "dedicated hardware for improving rendering performance" which the SVGA stuff would seem to fall squarely under.
reply
upvoteby layer810 hours ago|
parent|
next
[-]
The term GPU was first coined by Sony for the PlayStation with its 3D capabilities, and has been associated with 3D rendering since. In some products it stood for Geometry Processing Unit, again referring to 3D. Purely 2D graphics coprocessors generally don’t fall under what is considered a GPU.
reply
upvoteby ShroudedNight9 hours ago|
parent|
[-]
It has been associated with 3D rendering, but given that things like the S3 86C911 are listed on the Wikipedia GPU page, saying "Accelerated GUIs don't need GPU" feels like attempting to win an argument by insisting on a term definition that is significantly divergent from standard vulgar usage [1], which doesn't provide any insight to the problem originally being discussed.

[1] Maybe I've just been blindly ignorant for 30 years, but as far as I could tell, 'GPU' seemed to emerge as a more Huffman-efficient encoding for the same thing we were calling a 'video card'

reply
upvoteby layer88 hours ago|
parent|
[-]
I don’t agree with what you state as the vulgar usage. “Graphics card” was the standard term a long time, even after they generally carried a (3D) GPU. Maybe up to around 2010 or so? There was no time when you had 2D-only graphics cards being called GPUs, and you didn’t consciously buy a discrete GPU if you weren’t interested in (3D) games or similar applications.

In the context of the discussion, the point is that you don’t need high-powered graphics hardware to achieve a fast GUI for most types of applications that WPF would be used for. WPF being slow was due to architectural or implementation choices.

reply
upvoteby bombcar5 hours ago|
parent|
[-]
That's the real takeaway - WPF should have degraded gracefully (read, full speed performance without the bling) but it didn't.
reply
upvoteby bombcar9 hours ago|
parent|
prev|
[-]
Most people consider GPU to mean "3D accelerator" though technically it refers to any coprocessor that can do work "for" the main system at the same time.

GPU-accelerated GUI usually refers to using the texture mapping capabilities of a 3D accelerator for "2D" GUI work.

reply
upvoteby cyberax3 hours ago|
parent|
prev|
next
[-]
Calling that "the GPU acceleration" on Mac OS X was a bit overstating the things. It supported rotations, compositing, and some other bulk operations, but text and precise 2D graphics was rendered on the CPU.

It _still_ is not trivial to render high-quality 2D graphics on the GPU.

reply
upvoteby kalleboo17 hours ago|
parent|
prev|
[-]
I mean Apple had a GPU-accelerated GUI in 1990, but probably not what we think of "GPU accelerated" these days

https://wiki.preterhuman.net/Apple_Macintosh_Display_Card_8-...

reply
upvoteby seltzered_17 hours ago|
prev|
next
[-]
A notable example I remember from around 2010 was when Evernote dropped WPF, supposedly due to blurry text issues but probably also performance (remember when we called it EverBloat?)

Can't find the original blog post about it but here's a couple mentions of it:

- https://www.edandersen.com/p/evernote-has-no-patience-drops-...

- https://www.reddit.com/r/csharp/comments/x0nu7h/comment/im9k...

reply
upvoteby VorpalWay12 hours ago|
parent|
next
[-]
Blurry fonts was my main issue with WPF. I get headaches from blurry text and the colour bleeding from ClearType just makes the headache worse.

Fortunately for me, I had mostly switched to Linux by that time already, where it was at the time relatively easy to just enable grey scale AA with full hinting.

In recent years this has gotten worse again with modern software incorrectly assuming everyone has a High DPI monitor. My trick has been to use bitmap fonts with no AA, but that broke in recent versions of electron, where bitmap fonts are now rendered blurry. So I had to stay on an old version of vscode from last year, and I will be looking to switch to another editor (high time anyway for other reasons).

reply
upvoteby xmcqdpt29 hours ago|
parent|
[-]
emacs + bitmap font for me and I'm continually shocked when I have to use something else by how it is blurry and laggy.
reply
upvoteby ack_complete6 hours ago|
parent|
prev|
[-]
WPF originally had two major rendering issues. One was the lack of pixel snapping support, and another was gamma correction issues during text rendering, particularly for light text on a dark background (due to an alpha correction approximation, IIRC). The two combined led to blurry text in WPF applications.

These were finally improved for WPF 4, since Visual Studio 2010 switched to it and had a near riot in the betas due to the poor rendering in the text editor.

reply
upvoteby aleph_minus_one11 hours ago|
prev|
next
[-]
> Bear in mind, this is software that basically just displays text

Displaying text is surprisingly hard, as one can easily find out if ones dives into the big rabbit hole of font rendering.

reply
upvoteby mwcampbell11 hours ago|
parent|
[-]
Yes, text shaping and layout are complex. My point is that the program wasn't doing anything that should have required a GPU, particularly for the resolutions that were common back then.
reply
upvoteby bgrainger7 hours ago|
parent|
next
[-]
The promise was that WPF would use hardware-accelerated libraries such as DirectWrite to put text on the screen even faster than GDI+ (using the CPU) could do. The reality turned out to be quite different: multiple layers of abstraction and just plain inefficient WPF code [1] meant that users needed powerful CPUs and GPUs just to get reasonable performance.

[1] https://faithlife.codes/blog/2019/06/improving-wpf-text-disp...

reply
upvoteby chris_wot8 hours ago|
parent|
prev|
[-]
I’m knee deep in refactoring LibreOffice code around text rendering. I can assure you, it’s complex but it doesn’t require a GPU!
reply
upvoteby nottorp15 hours ago|
prev|
next
[-]
Hmm doesn't that sound like Apple's Tahoe/iOS 26? Effects upon effects upon more effects.
reply
upvoteby steve197715 hours ago|
parent|
next
[-]
iOS 26 runs surprisingly smooth on my iPhone 12 Pro Max though.
reply
upvoteby nottorp11 hours ago|
parent|
[-]
Runs like crap on my daughter's 12 mini.

Actually what does "surprisingly smooth" mean? Better than you expected? Or actually smooth?

reply
upvoteby steve19778 hours ago|
parent|
[-]
I had an Xperia for a while but kept my iPhone and then installed the iOS 26 beta on it. Expectation was that it would run but be pretty painful. Surprisingly, even the beta ran so fine that I sold the Xperia and switched back to iOS. And it's still my daily driver.
reply
upvoteby cyberax3 hours ago|
parent|
prev|
[-]
Not really. Ironically, WPF designers wanted to make things better by offloading the rendering onto the GPU. They also added DirectWrite that was supposed to provide high-quality text rendering with all the bells and whistles like layout for languages with complex scripts, in hopes of eventually offloading the text rendering as well.

But they just plain failed to execute well on this idea.

reply
upvoteby wiseowise13 hours ago|
prev|
next
[-]
2008 edition of “let’s rewrite it in react”.
reply
upvoteby sylens12 hours ago|
parent|
[-]
2008 had its own version of React and it was called Adobe Air
reply
upvoteby beAbU10 hours ago|
parent|
[-]
Adobe Air was just Flash wearing an ill fitting business suit.
reply
upvoteby ecshafer5 hours ago|
prev|
[-]
The fact that software to show the bible needs a GPU is funny in some kind of dystopian way. That is the kind of software that should work in 50k of memory.
reply