UI: Allow Integer Thumbnail Size Range #105815

Harley Acheson · 2023-03-15T23:44:12+01:00

Harley Acheson commented

2023-03-15 23:44:12 +01:00

Instead of four discrete thumbnail sizes, allow the user to instantly
zoom to any integer size from 16-256. This also changes the default to
96 from the current 128.

This is mostly a demonstration for @JulianEisel to look at. We had talked about his consideration of changing the default thumbnail size from the current "Normal" of 128 to 64, which is the current "Tiny" size. This would require defining another size below "Tiny" at perhaps 32x32.

But this PR demonstrates that we can remove these artificial discrete steps. It changes the default size to 96 but then allows the user to select any integer size from 16-256. The UI is clamped at 24-256.

If you try it you will see that it is much quicker to slide an integer value than to click a dropdown, ponder a choice, select and close. Here you see the resulting size as a live preview rather than having to guess at what "Tiny" means until you select and close the dropdown. It also feels much more dynamic and modern.

Instead of four discrete thumbnail sizes, allow the user to instantly zoom to any integer size from 16-256. This also changes the default to 96 from the current 128. --- This is mostly a demonstration for @JulianEisel to look at. We had talked about his consideration of changing the default thumbnail size from the current "Normal" of 128 to 64, which is the current "Tiny" size. This would require defining another size below "Tiny" at perhaps 32x32. But this PR demonstrates that we can remove these artificial discrete steps. It changes the default size to 96 but then allows the user to select any integer size from 16-256. The UI is clamped at 24-256. If you try it you will see that it is much **quicker** to slide an integer value than to click a dropdown, ponder a choice, select and close. Here you see the resulting size as a **live preview** rather than having to guess at what "Tiny" means until you select and close the dropdown. It also feels much more dynamic and modern. ![ThumbZoom.gif](/attachments/73d5ae99-c63d-47f9-9709-f6014b171990)

ThumbZoom.gif

2.4 MiB

👍 15 ❤️ 3

Harley Acheson requested review from Julian Eisel 2023-03-15 23:44:52 +01:00

Harley Acheson added this to the User Interface project 2023-04-07 19:23:01 +02:00

Albert commented

2023-04-10 12:30:48 +02:00

First-time contributor

Control this value with Shift+MMB shortcut would be coherent with the rest of Blender

👍 1

Harley Acheson referenced this pull request

2023-06-02 19:53:39 +02:00

UI: Size Range of Preview Thumbnails #108557

Harley Acheson force-pushed ThumbRange from 5ebdf6286c to d8b4529891

2023-06-28 20:29:44 +02:00

Compare

Julian Eisel commented

2023-07-27 12:42:10 +02:00

Question is still if we should go with an full range like here, or with a set of fixed values like in current Blender and improved in #108557. @dfelinto argues that it's better to have a few fixed sizes, so asset authors have a small set of fixed sizes to test and optimize for, instead of a rather wide, arbitrary range.

Instead of the Tiny, Small, Normal, etc., I'd just use the size explicitly, since this is useful info: 32x32, 64x64, ...

What do you think @pablovazquez?

Question is still if we should go with an full range like here, or with a set of fixed values like in current Blender and improved in #108557. @dfelinto argues that it's better to have a few fixed sizes, so asset authors have a small set of fixed sizes to test and optimize for, instead of a rather wide, arbitrary range. Instead of the _Tiny_, _Small_, _Normal_, etc., I'd just use the size explicitly, since this is useful info: _32x32_, _64x64_, ... What do you think @pablovazquez?

Harley Acheson commented

2023-07-27 18:18:49 +02:00

@dfelinto argues that it's better to have a few fixed sizes, so asset authors have a small set of fixed sizes to test and optimize for, instead of a rather wide, arbitrary range.

Personally would rather discourage that by getting rid of the arbitrary sizes. Asset authors who create thumbnails less than the maximum 256x256 will create suboptimal results for some of their users.

Instead of the Tiny, Small, Normal, etc., I'd just use the size explicitly, since this is useful info: 32x32, 64x64, ...

Those numbers are only seem useful when the Blender UI scale is exactly 1.0, the OS monitor scale is 100%, and when on a regular non-high DPI monitor.

> @dfelinto argues that it's better to have a few fixed sizes, so asset authors have a small set of fixed sizes to test and optimize for, instead of a rather wide, arbitrary range. Personally would rather discourage that by getting rid of the arbitrary sizes. Asset authors who create thumbnails less than the maximum 256x256 will create suboptimal results for some of their users. > Instead of the _Tiny_, _Small_, _Normal_, etc., I'd just use the size explicitly, since this is useful info: _32x32_, _64x64_, ... Those numbers are only seem useful when the Blender UI scale is exactly 1.0, the OS monitor scale is 100%, and when on a regular non-high DPI monitor.

Dalai Felinto commented

2023-07-28 10:40:52 +02:00

Hi @Harley, what did you mean by:

Personally would rather discourage that by getting rid of the arbitrary sizes.

On a side note I talked to Julian and I think we should go with the same naming we have in the Asset Browser (Tiny, ...). Leaving the specific pixel resolution to the tooltip/user manual. I was waiting to hear from Pablo though since I didn't want to influence his 2 cents here.

Hi @Harley, what did you mean by: > Personally would rather discourage that by getting rid of the arbitrary sizes. ------------- On a side note I talked to Julian and I think we should go with the same naming we have in the Asset Browser (Tiny, ...). Leaving the specific pixel resolution to the tooltip/user manual. I was waiting to hear from Pablo though since I didn't want to influence his 2 cents here.

Harley Acheson commented

2023-07-28 15:57:24 +02:00

@dfelinto - what did you mean by "Personally would rather discourage that by getting rid of the arbitrary sizes"

That was an argument for this PR, which allows thumbnails of any size, over #108557 which adds more arbitrary sizes (small, tiny, large, etc).

The underlying thumbnail images themselves are all, and always, 256x256 PNG images. These images are then shown at some size to users in the UI. So if asset creators are to optimize for any particular size it should be 256x256, as that will give optimal result for the wide range of users.

Optimizing for any particular output size seems a bit silly. When we are currently showing "small" thumbnails we are just scaling those 256x256 images down to 96x96. But that is only at 1x Resolution scale, with an OS monitor scale of 100%, and on a regular non highDPI monitor. Change any of these things and a "small" thumbnail will be shown at a different size. If I simply drag the File Browser window from one of my monitors to another those "small" thumbnails are now shown at 119x119.

Since the current sizes, and those in #108557, are just arbitrary I favor this PR which just allows much quicker access to any integer size between 16-256.

> @dfelinto - what did you mean by "Personally would rather discourage that by getting rid of the arbitrary sizes" That was an argument for this PR, which allows thumbnails of any size, over #108557 which adds more arbitrary sizes (small, tiny, large, etc). The underlying thumbnail images themselves are all, and always, 256x256 PNG images. These images are then shown at some size to users in the UI. So if asset creators are to optimize for any particular size it should be 256x256, as that will give optimal result for the wide range of users. Optimizing for any particular output size seems a bit silly. When we are currently showing "small" thumbnails we are just scaling those 256x256 images down to 96x96. But that is only at 1x Resolution scale, with an OS monitor scale of 100%, and on a regular non highDPI monitor. Change any of these things and a "small" thumbnail will be shown at a different size. If I simply drag the File Browser window from one of my monitors to another those "small" thumbnails are now shown at 119x119. Since the current sizes, and those in #108557, are just arbitrary I favor this PR which just allows much quicker access to any integer size between 16-256.

Harley Acheson added 2 commits 2023-09-08 20:29:13 +02:00

Merge branch 'main' of projects.blender.org:blender/blender into ThumbRange af63d34502

Merge branch 'main' of projects.blender.org:blender/blender into ThumbRange 2dec8f0915

Harley Acheson referenced this pull request

2023-09-13 19:29:26 +02:00

UI: Size Range of Preview Thumbnails #108557

Harley Acheson referenced this issue from a commit

2023-09-13 19:57:01 +02:00

UI: Allow Integer Thumbnail Size Range

Harley Acheson merged commit fa32379def into main

2023-09-13 19:57:01 +02:00

Harley Acheson deleted branch ThumbRange