UI: Allow Integer Thumbnail Size Range #105815

Merged
Harley Acheson merged 3 commits from Harley/blender:ThumbRange into main 2023-09-13 19:57:01 +02:00
Member

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

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)
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
First-time contributor

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

Control this value with Shift+MMB shortcut would be coherent with the rest of Blender
Harley Acheson force-pushed ThumbRange from 5ebdf6286c to d8b4529891 2023-06-28 20:29:44 +02:00 Compare
Member

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?
Author
Member

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

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.
Author
Member

@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
Harley Acheson merged commit fa32379def into main 2023-09-13 19:57:01 +02:00
Harley Acheson deleted branch ThumbRange 2023-09-13 19:57:02 +02:00
Sign in to join this conversation.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#105815
No description provided.