This update is focusing on small fixes, performance improvements, and getting some infrastructure ready for future releases.
Pen/stylus support (pressure sensitivity) is finally coming back in 4.3, but the initial groundwork for that is in this release. If you’re not using a pen or a stylus then you should see no difference in this release, but it’s also really important to verify that that’s the case! If anything has changed then it’s very important to report that to me. I’ve redone a lot of the input stack to use WM_POINTER if available, but the “classic” path is still there for handling regular mouse input.
To get this update, make sure you have "Also check for pre-release (beta) versions" enabled in Settings, and then click on the Check Now button. (Unfortunately alpha/beta releases are not currently available for the Microsoft Store version of the app.
There’s also a direct download link over on the forum.
Changes since 4.2.5:
- Improved input handling systems to use WM_POINTER, which enables glitch-free drawing when using a pen or stylus (e.g. Surface w/ Pen) (see here: https://forums.getpaint.net/topic/113173-the-first-5mm-of-a-freehand-line-are-straight-when-using-a-tablet/ ). This will also be the basis for adding pressure sensitivity in a future release (v4.3). Note that Windows 7 is unaffected by this.
- Greatly improved performance of layer thumbnails when switching between images
- Fixed a crash (OutOfVideoMemoryException) on systems with hybrid GPU setups that are configured wrong. This seems to be a bug in Windows and DirectX. A "hybrid GPU" setup is an Intel iGPU or AMD APU paired with a discrete GPU in a laptop.
- Improved handling of the dreaded "NoHardwareDeviceException" crash: The user will be notified of how to fix this. It happens only on 2nd generation Intel Core systems with NVIDIA "Optimus" GPUs (GeForce or Quadro) when the NVIDIA Control Panel is set to force apps (or just Paint.NET) to use the NVIDIA GPU. This is a bug in the NVIDIA driver and/or in DirectX.
- Improved performance of Move Selected Pixels, Shapes, and Gradient tools when releasing the mouse button at the end of drag-and-drop gesture. Previously, anything rendered between the last mouse "move" and "up" events was re-rendered, resulting in the appearance of a delay/lag.
- Fixed some clipboard image handling for plugins (regular Copy/Paste is unaffected)
- Improved window chrome/theming when the app is running in Remote Desktop on Windows 10
- Fixed images being pasted incorrectly from Outlook 2016/365. This is actually a bug in Outlook: it puts PNGs on the clipboard that are arbitrarily cropped and scaled for some reason, and specifies they are the preferred format to use when pasting. This completely boggles my mind, it’s just really weird, I can’t imagine why it’s done this way.
- Changed: The size of the default/initial image ("Untitled") is now scaled exactly by system DPI setting (previously scaled by integer/floor of DPI setting). So at 150% DPI scaling this image will now be 1200×900 instead of 800×600.
- Fixed some high-DPI layout bugs with the Layer Properties dialog, while also preparing this UI for future additions
- Updated bundled WebPFileType plugin to v1.3.1.0 (thanks @null54!)
- Updated bundled DDSFileTypePlus plugin to v1.9.8.0 (thanks @null54!)
- Changed: SSE2 is now required for 32-bit/x86 systems (prevously, only SSE was required). See blog post: https://blog.getpaint.net/2019/10/14/paint-net-v4-2-6-will-require-sse2-on-32-bit-x86/
paint.net blog 
“Changed: The size of the default/initial image (“Untitled”) is now scaled exactly by system DPI setting (previously scaled by integer/floor of DPI setting). So at 150% DPI scaling this image will now be 1200×900 instead of 800×600.”
Why does this methodology have to be used? Why is there not an option to use 19201080, my laptop pixel size? I have to circumvent this behavior by opening a black 19201080 png image I previously prepared for the purpose.
Defaulting to an image size that’s the same dimensions as the screen would result in it being zoomed out, for one. That doesn’t really fit the purpose of the default image — although, to be fair, the purpose of the default image has kind of been lost to time. Originally it was to get you immediately started with a drawing surface that was a reasonable size and that wasn’t covered up by the floating forms too much. Nowadays it’s mostly “there’s a default blank image because otherwise the app seems weird without it” (part of which is because half the UI is disabled, and you can’t even move the floating forms)
I’ve had a lot of requests for being able to add something like a dropdown selector in File->New with a bunch of common, and customizable, image sizes. Just hasn’t reached high enough priority yet in comparison to everything else that’s going on.
“Defaulting to an image size that’s the same dimensions as the screen would result in it being zoomed out, for one.” As a user who wants to paint an image on a black background, if I pre-make a 1920×1080 blackimage and then later open paint,net and go to file – open – blackimage, paint.net thinks it’s working with a 1920 x 1080 image but has no problem automatically shrinking the displayed image to fit other desired features you mention. Hope this clarifies my user perspective.
What I miss from my treasured old Netstudio Web Graphics pkg is the TEXT combo of engrave, emboss and shadow.