I have encountered strange results, which may be a bug when using my script with 125% font size which is 120 DPI. Im usually using AHK_H on Win7 32-bit, but get the same results with AHK 1.1.16.05. The strange results are radiobuttons and checkboxes has irregular/unsymetrical y spacing between them in my gui script. Testing the same script with 96 and 144 DPI the spacing is perfectly symetrical. The problem only occurs when using 120 DPI and are specifical visible between radiobuttons. Perhaps there is a bug in the AHK 120 DPI-awareness code?

Note that DPI scaling will essentially multiply Gui coordinates (xywh) by 1.25 in your case and then drop the fractional part, therefore introducing potential precision loss and oddities regarding separation. There is nothing we can do about that (except maybe rounding instead of truncating, but it would be IMO not worth it), Win32 doesn't support fractional control positions/sizes.

Images in PictureControls are awfully scaled when using anything above the default of 96 DPI. There must be plenty of room for improvements in this area, Yes? It is quite sad AHK GUI does so badly with larger DPI's A few samples which displays the crappy result in AHK Gui's. PictureControl image is compared with the same image opened in Win10_64 Metro Photo Viewer app:

Wow, over 1500 viewers on my last post, thanks Did anyone of all the viewers try to confirm they have the same AHK GUI picture scaling problem on higher DPI settings on their systems? Need your help, cuz it would not do anything good to the case if it turns out the AHK GUI picture scaling problem is specific to my system only

Apparently this is an interesting topic for lots of people and it is not surprising cuz the 4K monitors/TVs are here for reasonable prices and using 96 DPI with such a "badboy" is simply impossible unless using a magnifying glass. With a high resolution TV/Monitor you need to be using at least 120 DPI or even higher to get a nice experience. Considering that having the AHK GUI picture scaling working for all DPI settings are on the verge of being imperative in these times IMHO.

So fincs or lexikos, are the final word already said regarding this topic or is there a chance any of you might overhaul it once again down the road?

related to pictures I think you cannot call it a 'DPI-awareness bug'. Your sample picture fits exactly the size of the picture control for 96 DPI. If you try to load the picture into a bigger control still using 96 DPI it needs to be upscaled, too, and the result seems to be the same. Adding the AltSubmit option to force AHK to use GDI+ for .jpg files might provide slight better results. It depends 'on the eye of the beholder'.

related to pictures I think you cannot call it a 'DPI-awareness bug'. Your sample picture fits exactly the size of the picture control for 96 DPI. If you try to load the picture into a bigger control still using 96 DPI it needs to be upscaled, too, and the result seems to be the same. Adding the AltSubmit option to force AHK to use GDI+ for .jpg files might provide slight better results. It depends 'on the eye of the beholder'.

The King of GUI's saves the day yet again Thanks, Just me, you are the best Im still confused about this recently arised image scaling issue, cuz I can swear the AHK GUI image control scaling was just fine without the AltSubmit option prior to a large Windows 10_x64 update early this year. I wonder if MS did something which affects the access of graphics hardware and ultimately affects AHK image control upscaling. Haven't changed graphics card or anything. Have been using that same AHK application (yeah it's that one ) every day for 1 1/2 year now and never seen these skewed images before. That is why I though the issue could be categorized as a 'DPI-awareness bug', but is more likely a MS intoduced bug.

When trying to work out for the past two months what was wrong after the update, I even experimented with the AltSubmit option, but didn't see those nice results as you get. I can't believe how I could mess that up The pictures in my script are loaded into a bigger GUI text control which doesn't exactly fit the size of the picture control for 96 DPI. With AltSubmit everything is back to where it was and the image control auto-resizer (depending on the text control size) with kept aspect ratio works nicely again Thanks!

Maybe it is time for AHK to do a swap and use AltSubmit as the normal/default loading method considering the less nice result of todays default and if GDIPlus is not available revert to the previous normal loading method. Its impossible to say if MS has introduced a bug or alternative handling for good.