#2107 GTK3: Image contents box looks bad

[rice123]

1. File -> Smart attach.
2. Select any disk image.

There are 2 problems with the image contents box: it's too narrow so using the horizontal slider is required even if there's ample space to display everything, and characters are cut off at the bottom. A screenshot is attached.

Installed charset: C64 Pro Mono v1.21 from Style
Display resolution: 3840x2160
DPI scaling: 150%

[gpz]

please try if it is ok with 100% scaling (if still broken, it must be the high resolution)

[rice123]

Both problems persist when 100% DPI scaling is used.

[rice123]

I've also tested half the native size, i.e. 1920x1080, and it's still bad, so the issues don't seem to be related to any particular resolution.

[compyx]

Is this the latest 3.9 release? And what Windows version are you using?

[compyx]

Could you post a screenshot of the About dialog? (Help -> About VICE...) That should show some version numbers of the used libraries (like Pango and Cairo).

[rice123]

GTK3VICE-3.9-win64, Windows 10 22H2. The libraries are included with VICE and loaded from the "bin" directory where x64sc.exe is launched from, according to the DLL search order in Windows. Process Explorer confirms that both libcairo-2.dll and libpango-1.0-0.dll are loaded from C:\C64\GTK3VICE-3.9-win64\bin\

[gpz]

Interestingly on my laptop (also 22H2) its all perfectly fine. wth

[rice123]

We can hunt for the unknown breaking factor. Can you take a screenshot as well? I thought that might be due to some font revision difference, but it looks like VICE loads the charset from /GTK3VICE-3.9-win64/common/C64_Pro_Mono-STYLE.ttf, so at least that should make no difference.

[gpz]

(yes the dialog is actually larger than my desktop)

[Querino]

looks fine here, win 11 22h2

[rice123]

It's very weird that the width of the box is different, indeed. The key to solving this bug is to figure out what could influence that. I can provide logs and run tests if necessary.

[rice123]

Oooookay, so I've grepped code for "Image contents" and found content_preview_widget_create() in /src/arch/gtk3/widgets/contentpreviewwidget.c, which does this:

gtk_widget_set_size_request(scroll, 420, -1);

The width of the image content box on my machine is exactly 420. I downloaded and checked your screenshots and they're 420 pixel wide too. So it seems that the width is the same, and what makes the difference is the font being smaller in your case.

[rice123]

I think I've found the reason why the font is too big here: it's about DPI scaling after all. The DPI awareness of VICE is "System Aware". x64sc.exe doesn't specify any DPI awareness in the manifest, so it starts with "Unaware", but then GTK calls SetProcessDpiAwareness():

[0x0]   USER32!SetProcessDpiAwarenessInternal   0x89eabff628   0x7fff39208c7b   
[0x1]   shcore!SetProcessDpiAwareness+0xb   0x89eabff630   0x7ffedcda3302   
[0x2]   libgdk_3_0!gdk_win32_pixbuf_to_hicon_libgtk_only+0x7772   0x89eabff660   0x7ffee298b7ca   
[0x3]   libgobject_2_0_0!g_type_create_instance+0x26a   0x89eabff6d0   0x7ffee296dde1   
[0x4]   libgobject_2_0_0!g_object_unref+0x9b1   0x89eabff7e0   0x7ffee296fdd2   
[0x5]   libgobject_2_0_0!g_object_new_with_properties+0x1f2   0x89eabff870   0x7ffee2970c23   
[0x6]   libgobject_2_0_0!g_object_new+0x53   0x89eabff910   0x7ffedcda4d48   
[0x7]   libgdk_3_0!gdk_win32_display_get_type+0x138   0x89eabff950   0x7ffedcd6e132   
[0x8]   libgdk_3_0!gdk_display_manager_open_display+0xf2   0x89eabffa40   0x7ffedc2cb5b4   
[0x9]   libgtk_3_0!gtk_init_check+0x14   0x89eabffae0   0x7ffedc2cb6dd   
[0xa]   libgtk_3_0!gtk_init_abi_check+0x5d   0x89eabffb10   0x7ff68b773028   
[0xb]   x64sc+0x213028   0x89eabffb50   0x7ff68b57b94a   
[0xc]   x64sc+0x1b94a   0x89eabffb90   0x7ff68b819994   
[0xd]   x64sc+0x2b9994   0x89eabffc70   0x7ff68b561319   
[0xe]   x64sc+0x1319   0x89eabffcb0   0x7ff68b561406   
[0xf]   x64sc+0x1406   0x89eabffd00   0x7fff39307374   
[0x10]   KERNEL32!BaseThreadInitThunk+0x14   0x89eabffd30   0x7fff394bcc91   
[0x11]   ntdll!RtlUserThreadStart+0x21   0x89eabffd60   0x0   

If you look at https://learn.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows you can find this useful information about this mode:

"System DPI Awareness

Desktop applications that are system DPI aware typically receive the DPI of the primary connected monitor as of the time of user sign-in."

This is important to understand why the font was still too big after setting the DPI scaling to 100%. That's because the app would still pick 150% used when I logged in to Windows.

If this analysis is correct then the box will be too narrow for any user who has logged in to Windows with a DPI scaling factor being over 100%. The hardcoded widget width of 420 (blaze it) won't fit that.

[compyx]

Thanks for figuring all that out =)

I've indeed hardcoded the width of the widget to 420, otherwise Gtk would constantly adjust the width of the widget, making for some very odd looking dialog when selecting different files.
There's also some trickery with negative vertical margins going on to make the individual rows of the directory listing (a GtkTreeView) not have spacing between the lines for proper dir art. That falls apart as you can see with any scaling other than 100%.

I've already been trying to get Gtk to resize the widget from 420 to something more when the contents of the tree view don't fit 420, but Gtk isn't being very cooperative at the moment. But even if I get the width set properly we'd still have the issue of the row margins being incorrect with a non-100% font scaling.

Probably the best solution would be to just render the font ourselves with Cairo in a custom widget, directly from the CHARGEN data, skipping Pango (the font rendering lib) and the CBM Pro Mono font altogether. Either Cairo would adjust the widget's size to the proper DPI setting, or we can request the current scaling required through Gdk (something I'd have to figure out).

That would require quite a rewrite of some code, but would free us from the current horrors of registering the CBM Pro Mono font on Windows and making Pango actually recognize it (another source of frustration since Pango went from using GDI to DirectWrite for font rendering on Windows).

[compyx]

Seems like gdk_screen_get_resolution() might provide us with the DPI scaling factor which can then be used to set the proper widget size and row margins/padding.

If any of this will actually work on Windows is anyone's guess. I won't have access to a Windows machine until early January, so it'll take a little while before we find out.