Give us a progress bar

SketchUp Feature Requests
1

The most helpful thing you could possibly to for your next SketchUp and Layout version is to include a progress bar. I work with large files, and sometimes get the spinning beachball on every single operation (such as, for example, deleting a text box in Layout). Sometimes these operations take several minutes to complete. Without a progress bar I have no idea whether the program has hung or is just churning. Incredibly frustrating.

7 Likes
2

Moved to feature requests.

Adobe has had this for many years, with the option to turn on an audible indicator of completion (very helpful when multi tasking).

1 Like
3

The spinning beachball (or “wait cursor”) is usually a sign that the UI process (which responds to inputs or renders the user interface) is unresponsive or busy, because it does a lot of work. This can be the case if the same process handles UI and application logic (geometric operations etc.). A progress bar would require the UI process to be responsive to update the progress bar.

So this can be solved:

  • by making SketchUp more responsive and ensuring UI and geometric operations are separated where possible.
  • or on the OS side by giving better feedback to the user when an unresponsive application (spinning beachball) becomes responsive again. For example some OS like mine show an unobtrusive notification “Application XYZ is ready.” when an application has finished the startup ceremony or has become responsive after a certain time of unresponsiveness.
1 Like
4

so, so true.

5

There are a few SU extensions with progress indicators which are very helpful.

Again, helps with multi tasking, you have a good idea of when the process will complete.

AS @Aerilius notes, it tends to have a lot to do with the UI, in which case having a powerful GPU running SU should help.

1 Like
6

No, GPU is unrelated (only helpful for the 3D viewport). As I said, the UI toolkit (rendered on the CPU) is only responsive if the heavy work (geometric operations, explode, intersect, follow-me, Ruby interpreter) is done in a separate, concurrent thread, not in the UI thread.

7

I falsely assumed the viewport and UI would be using the same thread…

So, is there more work SU can do to separate processes / threads to improve efficiency?

8

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.