As someone who does raw Win32 API based UI... no. The Win32 UI system has been neglected for many years and is missing very basic functionality by modern standards, including dark mode support, antialiased rendering, hardware accelerated image stretching, and wide color gamut / HDR support. You're going to be working around a lot of ancient restrictions compared to a more modern UI and rendering layers on top of it.
It's also a basic implementation, doing a divide per sample to renormalize and not taking advantage of the symmetry of the kernel.
Even on a GPU, you wouldn't use an algorithm this simple in production. For small radii, leveraging bilinear filtering halves the number of samples. For larger radii, hierarchical pyramid approximations are popular.
Segment overrides were also painless to use, a single byte segment prefix byte was all that was needed to revector a memory operand to a different segment selector for the next instruction. With bank switching you'd have to use extra instructions and/or registers to switch the banking window to the desired bank and back, and possibly bounce to a routine in RAM to do that if you only had one banking window (which was quite common).
Banking registers also weren't always readable, in which case either you'd need to shadow the banking register or avoid nested/interrupt scenarios.
I'd prefer 8086 segmentation any day over the headache of trying to execute 6502 code from a bank-switched cartridge with a single banking window and a write-only banking register.
Precise and consistent fill conventions don't need barycentric coordinates, it simply needs some care in rasterization. Chris Hecker's 1985 texture mapping series in Game Developer covered how to do this properly in a traditional software scanline rasterizer. The necessary prestepping isn't expensive.
One of the sillier regressions, which was thankfully fixed, was that the new Paint used to draw the marching ants animation around a selection regardless of whether the app was in the foreground. An instance of Paint with a rectangular selection would eat 5% of the GPU continuously in the background.
You're assuming that the asm syntax is targeted at human readability, when it's at least as much to ease the complexity of the assembler and disassembler.
If the FMA instruction syntax was designed for readability, then it would have used 4-argument syntax with a requirement for two registers to match instead of using the 1/2/3 encodings. But the reason why it uses those names instead is that it's more consistent with the instruction encoding and the format of most other vector instructions: the register/memory argument is last.
Similarly, x86 vector instructions that take an immediate byte cram a bunch of options into that byte, such as shuffle masks or operation options. The assembly syntax does not help constructing this byte at all. But that's because it's meant to map straightforwardly to the instruction encoding, not to be easy to manually read or write.
ARM assembly tends to be a bit more consistent, but has some similar quirks. The majority of ARM instructions are dst,src, but store instructions are reversed as src,dst so they have the memory argument second just like load instructions.
>You're assuming that the asm syntax is targeted at human readability, when it's at least as much to ease the complexity of the assembler and disassembler.
I think you misunderstand my meaning. I know why things are like this. I was musing on the consequences of that. When the target moved aware from human readability then it also actively discourages human attention, lessening the chance of innovation. In my own work, I have always thought that maximising the general utility of things is better than targeting a 'use case' so that others might come up with ideas for use that I hadn't considered.
A worrying thought is that companies might be motivated to discourage innovation outside of their own control.
They've also used Detours within Windows itself. The auto super resolution (AutoSR) feature works by dxgi.dll detouring specific calls in user32.dll, in-process, to virtualize certain monitor metrics. I found this out because it was broken for a while on Windows 11 ARM64 when it couldn't handle PAC-enabled function prologs and enabling it would just crash programs by corrupting user32 functions.
No. API Sets use forwarding within the loader and are largely transparent to regular/delayed binding and GetProcAddress(). That would be fine. This is overwriting the prologue of the function in user32.dll similar to any other user-space hooking library.
reply