DPI-awareness bug?

Report problems with documented functionality
zcooler
Posts: 277
Joined: 11 Jan 2014, 04:59

DPI-awareness bug?

22 Nov 2014, 19:13

Hi!

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?

This is the script you can test with:
Spoiler


Add some source and destination folders and some shows to your liking or use this ini, which should be saved and placed in the same folder as the script.

Code: [Select all] [Download] (Script.ahk)GeSHi © Codebox Plus

[Source_Folders]
Key=D:\TV\Recording Service|D:\Edited Recordings|E:\|D:\
[Destination_Folders]
Key=E:\TV\Unedited|E:\TV\Edited|E:\|D:\
[Show_titles_name]
Key=American Chopper|Arga snickaren|Gold Divers|Gold Rush|Gordon’s Kitchen Nightmares|Hell’s Kitchen|Hundra procent bonde|Ice Cold Gold|Ink Master USA|Jungle Gold|Mannen som talar med hundar|Mythbusters|Solsidan|Tidsresenärerna|Top Gear|Ullared|Whale Wars|Wheeler Dealers
User avatar
fincs
Posts: 493
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: DPI-awareness bug?

22 Nov 2014, 19:25

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.
fincs
Windows 10 x64 Build 14393 / AutoHotkey v1.1.24.04
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]
just me
Posts: 3976
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: DPI-awareness bug?

23 Nov 2014, 04:44

fincs wrote:Note that DPI scaling will essentially multiply Gui coordinates (xywh) by 1.25 in your case and then drop the fractional part ...
?
As far as I can see you're using MulDiv().

Also:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


aOpt.x = mPrevX + mPrevWidth + Scale(ATOI(next_option + 1));
This uses 3 values which are rounded separately. This might affect precision.
Except as noted otherwise all of my code is tested on Win 10 Pro (x64) using the current AHK version.
zcooler
Posts: 277
Joined: 11 Jan 2014, 04:59

Re: DPI-awareness bug?

27 Feb 2017, 15:28

Hi Again!

I wonder if you could do something about this problem? Perhaps look into what Just me points out might improve the DPI scaling if using 120 or 144 DPI.
aOpt.x = mPrevX + mPrevWidth + Scale(ATOI(next_option + 1));
This uses 3 values which are rounded separately. This might affect precision.

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:

96 DPI
96 DPI.jpg
96 DPI.jpg (38.08 KiB) Viewed 5808 times

120 DPI
120 DPI.jpg
120 DPI.jpg (48.86 KiB) Viewed 5808 times

144 DPI
144 DPI.jpg
144 DPI.jpg (61.81 KiB) Viewed 5808 times


Test image file can be downloaded here:
https://images-na.ssl-images-amazon.com ... 68_AL_.jpg

Code: [Select all] [Download] GeSHi © Codebox Plus

Gui, RaggedPicture:New, +Caption ; -Border
Gui, Margin, 0, 0
Gui, Color, FFFFFF
Gui, Font, s9, Arial
Gui, Add, Picture, w182 h268, F:\TV\test\M.jpg
Gui, Show, w182 h268, RaggedPicture
zcooler
Posts: 277
Joined: 11 Jan 2014, 04:59

Re: DPI-awareness bug?

07 Mar 2017, 12:15

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?
lexikos
Posts: 5090
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: DPI-awareness bug?

07 Mar 2017, 21:47

I assume it's a result of whatever image scaling method was used. It's not something I'm interested enough to look into, but if someone comes up with a fix I may merge it.
just me
Posts: 3976
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: DPI-awareness bug?

08 Mar 2017, 04:50

Hi zcooler,

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'.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

Except as noted otherwise all of my code is tested on Win 10 Pro (x64) using the current AHK version.
Guest

Re: DPI-awareness bug?

08 Mar 2017, 07:15

What happens if you resize the images using GDI+ (you can use A_ScreenDPI to see if you need to resize them) - it may produce better quality (just a wild guess)
guest3456
Posts: 1858
Joined: 09 Oct 2013, 10:31

Re: DPI-awareness bug?

08 Mar 2017, 10:54

just me wrote:Adding the AltSubmit option to force AHK to use GDI+ for .jpg files might provide slight better results


Looks way better here and probably what he's looking for

zcooler
Posts: 277
Joined: 11 Jan 2014, 04:59

Re: DPI-awareness bug?

08 Mar 2017, 14:45

just me wrote:Hi zcooler,

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 :mrgreen: Thanks, Just me, you are the best :D 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 :facepalm: 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 :D 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.

Best regards
zcooler

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 4 guests