Icon view doesn't properly adapt to 2x Window scaling

With the default XFCE 1x window scaling, xlarge thumbnails look like this:

But when going in XFCE's Appearance > Settings and setting Window Scaling to 2x, then zooming to get the same grid size (as shown by the blue background on the selected file matching with the previous image), thumbnails use the large size instead of xlarge:

This issue applies to further zoom levels.

I think either the thumbnails should be bigger or the grid should be smaller, in order not to waste screen space.

Specs:

• Debian 12 XFCE edition
• Thunar 4.18.4

added 5. Icon View 5. Thumbnails 5. Window Scaling labels

Thanks for reporting, though I cannot reproduce with thunar master or thunar 4.18.x

Here what I see:

thunar master

thunar 4.18.x

Did you possibly tweak the scaling in a different way ?

Furthermore, there is already #693 which is about maximizing the shown thumbnails / minimizing the ammount of background shown.

added 3. Need Info label

As stated in my report, I'm using the Appearance dialog, not the Display dialog, which doesn't produce the same effect.

All settings other than those I mention in my report are left to their default values.

I would add that even in your screenshots, there's a lot of wasted vertical screen space, which may be worth another issue.

Ok, thanks, now I as well can reproduce.

I don't have time to look into this. Further investigation / a fix would be very welcome!

I would add that even in your screenshots, there's a lot of wasted vertical screen space, which may be worth another issue.

Sure, though out of scope of this issue / to be fixed via #693. Afaik we as well have some bug for increasing the file-names together with the thumbnails, though I currently fail to find it.

Thanks. About the file names, were you looking for #255 ?

Yea, that's the one. Thanks for linking!

removed 3. Need Info label

We probably have to adjust thunar_icon_size_to_thumbnail_size() so that it considers the scale factor.

Example: Increasing the factor from 1x to 2x would shift ThunarThumbnailSize by 1.

A proper fix may also require the following change: 9657a282 (comment 75737)

I am not sure how/where to properly add the missing scale factor so that the icon view uses the correct thumbnail size.

@alexxcons @kelnos Any ideas?

Not sure what the thumbnail sizes are, but should be fine to just use whatever thumbnail is 2x the size that'd be used on a 1x UI scale, and then load it into a cairo_surface_t with the surface's scale factor set to 2.

Unfortunately I don't recall how/where the thumbnails in the icon view get loaded...

The following changes give the correct result, but querying the scale factor should happen elsewhere (I think):

 static ThunarThumbnailSize
 thunar_icon_size_to_thumbnail_size (ThunarIconSize icon_size)
 {
+  icon_size *= 2; // scale factor
+
-  if (icon_size >= THUNAR_ICON_SIZE_1024)
+  if (icon_size > THUNAR_ICON_SIZE_512)
     return THUNAR_THUMBNAIL_SIZE_XX_LARGE;
 
-  if (icon_size >= THUNAR_ICON_SIZE_512)
+  if (icon_size > THUNAR_ICON_SIZE_256)
     return THUNAR_THUMBNAIL_SIZE_X_LARGE;
 
-  if (icon_size >= THUNAR_ICON_SIZE_128)
+  if (icon_size > THUNAR_ICON_SIZE_128)
     return THUNAR_THUMBNAIL_SIZE_LARGE;
 
   return THUNAR_THUMBNAIL_SIZE_NORMAL;
 }

That looks reasonable. You can probably just pass the scale factor into that function as a separate parameter.

The function is located and only called in thunar-enum-types.c which does not deal with GUI elements.

thunar_zoom_level_to_thumbnail_size calls it, which itself is called in thunar_standard_view_set_zoom_level.

Inside there one could do scale_factor = gtk_widget_get_scale_factor (GTK_WIDGET (view)); and pass the scale_factor down to thunar_icon_size_to_thumbnail_size.

Not sure for it's other caller, thunar_thumbnail_size_from_icon_size … maybe a factor of 1 would do the job ?

Not sure for it's other caller, thunar_thumbnail_size_from_icon_size … maybe a factor of 1 would do the job ?

My tests show that the correct factor needs to be (somehow) passed to thunar_thumbnail_size_from_icon_size so that the thumbnails appear properly sized.

Ah, that's super annoying; it's buried in a place where there's no way to pass additional information. Looks like ThunarStandardView binds the icon renderer's size to the ThunarThumbnailer's thumbnail-size, and that enum GValue conversion magic converts the pixel size of the icon renderer into a thumbnail size.

I think there's a different way to fix this, though: stop using the "default". It looks like the thumbnailer's thumbnail-size can be overridden on a per-thumbnail-request basis. thunar_thumbnailer_queue_file() and thunar_thumbnailer_queue_files() take a size parameter. ThunarStandardView always passes THUNAR_THUMBNAIL_SIZE_DEFAULT, which causes the thumbnailer to use the value of its thumbnail-size property.

Instead, in ThunarStandardView, where it makes those thumbnailer API calls, you could check the size property of the icon renderer, and then "combine" that with the view's scale-factor property to get a proper-sized thumbnail size. Then explicitly pass that thumbnail size to the thumbnail queuing functions instead of passing _DEFAULT.

I'm not 100% sure the size property on the icon renderer will be valid at all times (might only be valid when the cell renderer is rendering?), so might take a little experimentation to get that right.

Hi @kelnos & @lastonestanding , could you guys test if this issue still persists after !396 (merged)

It does. Did it change for you with the merged changes?

I still need to apply the experimental change from my previous comment to get the correct result.

But now that thumbnailer size is no longer bound to icon renderer size in standard view it would be easier to implement your solution right ?

The correct required size is passed onto thumbnailer from one of the func inside icon factory. And this call does not use the default option of thumbnailer. So you could now nicely apply your logic ?

Does this 1143.diff patch solve the issue ?

Yes, that diff plus the modified icon_size comparisons solve the issue.

@lastonestanding Should I open an MR or would you like to open an MR regarding this?

Thanks for opening the MR. I was busy, so I could not respond on time.

mentioned in issue #117

changed the description

mentioned in issue #1182 (closed)

mentioned in merge request !401 (merged)

closed with commit 58fc8e55

changed milestone to %4.19.0

mentioned in issue #1400 (closed)

marked #1400 (closed) as a duplicate of this issue

marked this issue as related to #1400 (closed)