UI: Visual Differentiation for Thumbnails in Progress #107380

New Issue

Harley Acheson · 2023-04-26T19:41:08+02:00

Harley Acheson commented

2023-04-26 19:41:08 +02:00

We get occasional complaints that when thumbnailing folders of images some are not being done or not shown when expected. Although there are, and have been, errors in this process a big problem is that we don't actually give users feedback on what is happening.

If you go to a folder of new images that have never been thumbnailed the icons will initially be shown with a generic "image" icon. Then we create thumbnails in background threads (one per core) and we show them when completed.

The first lack of feedback is that we don't differentiate between "not done yet" and "failure". So if we are unable to read the file or create the thumbnail it just continues to show the same generic image icon. So an error just appears to be one that is taking forever.

For errors we could think of a new container image or perhaps use a different icon or other change. Simplest might be to just dim the failures:

Or perhaps do so and also change the icon to one of ours that indicates "broken file":

Just doing the above would go a long way to explaining to users what is happening. But another step might be to also indicate which items are being actively processed. Perhaps something like this?

That way users would watch them start as generic icons, see groups of them shown as being worked on, and when each is done they change to the final image or to the "broken file" version.

Of course the above is talking about thumbnails of images, but this applies to other file types and Assets too.

We get occasional complaints that when thumbnailing folders of images some are not being done or not shown when expected. Although there are, and have been, errors in this process a big problem is that we don't actually give users feedback on what is happening. If you go to a folder of new images that have never been thumbnailed the icons will initially be shown with a generic "image" icon. Then we create thumbnails in background threads (one per core) and we show them when completed. The first lack of feedback is that we don't differentiate between "not done yet" and "failure". So if we are unable to read the file or create the thumbnail it just continues to show the same generic image icon. So an error just appears to be one that is taking forever. For errors we could think of a new container image or perhaps use a different icon or other change. Simplest might be to just dim the failures: ![ThumbError.png](/attachments/d06a944c-e0ef-4f0b-9f99-bcf390011df6) Or perhaps do so and also change the icon to one of ours that indicates "broken file": ![ThumbError.png](/attachments/335e7f73-c8d6-45c2-aedf-aedf222c3a17) Just doing the above would go a long way to explaining to users what is happening. But another step might be to also indicate which items are being actively processed. Perhaps something like this? ![ThumbWait.png](/attachments/989f5068-6159-42c9-9a47-a223f06f4aa6) That way users would watch them start as generic icons, see groups of them shown as being worked on, and when each is done they change to the final image or to the "broken file" version. Of course the above is talking about thumbnails of images, but this applies to other file types and Assets too.

ThumbWait.png

11 KiB

ThumbError.png

8.9 KiB

ThumbError.png

16 KiB

Harley Acheson added the

Type

Design

label 2023-04-26 19:41:08 +02:00

Harley Acheson added this to the User Interface project 2023-04-26 19:41:09 +02:00

Harley Acheson referenced this issue

2023-04-26 20:11:39 +02:00

Regression: Image thumbnails in file browser sometimes do not show up #107212

antonheg commented

2023-05-05 17:28:41 +02:00

When metadata is deleted, PNG files display normally:

exiftool -ext png -overwrite_original -all= .

That said, how would you tell every developer to clean-up metadata on his PNG files before shipping an add-on?

When metadata is deleted, PNG files display normally: `exiftool -ext png -overwrite_original -all= .` That said, how would you tell every developer to clean-up metadata on his PNG files before shipping an add-on?

Harley Acheson commented

2023-05-05 18:05:11 +02:00

PNGs having metadata isn't the problem. The error is that some PNGs are not being detected as such.

👍 1

Harley Acheson commented

2023-05-31 21:41:10 +02:00

Note that the above still results in "flashing" when loading a series of items that already have thumbnails created. Even though there is no real work to be done we still start with generic icons - that are mostly white - before the final images are loaded. It is worth considering making the initial image blank. And then the "loading" version could be mostly transparent with just the clock or hourglass having text color.

Harley Acheson referenced this issue

2023-06-01 18:32:19 +02:00

UI: Improved Preview Feedback and Reduced Flickering #108486

Harley Acheson commented

2023-06-19 22:53:49 +02:00

Closing this because the issues raised here were implemented in #108486

Any points in this document that were not implemented are for good reason. For example error indication doesn't not work as described above as we still want to see the document type. Basically #108486 nicely addresses the central issues mentioned here.

Closing this because the issues raised here were implemented in #108486 Any points in this document that were not implemented are for good reason. For example error indication doesn't not work as described above as we still want to see the document type. Basically #108486 nicely addresses the central issues mentioned here.

Harley Acheson closed this issue

2023-06-19 22:53:51 +02:00

Blender Bot added the

Status

Archived

label 2023-06-19 22:53:51 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

UI: Visual Differentiation for Thumbnails in Progress #107380