Timers / estimates & abortable operations + cost/benefit feature

SketchUp Feature Requests
1

Two relatively simple changes that would save MILLIONS of user-hours:

1.) Before any operation, have a subroutine calculate / count the number of sub-units in question, and display an estimate of the time it would take.

2.) Allow the user to ABORT the operation if it’s taking way too long.

There are way too many situations where you start something like a cleanup process, or component purge, or some complex geometry transformation, and… you wait… and you wait… and you wait some more… and the worst part is, you do not know if it will finish in the next 5 seconds, 5 minutes, or 15 hours.

If it’s 5 seconds, I’ll wait.
If it’s 5 minutes, I’ll take a coffee break.
If it’s 15 hours, I’d rather abort it and schedule it for the end of the work day so it can run overnight, OR IN A DIFFERENT PROCESS.

There’s simply no way to know, and it’s very nerve-wracking and time-consuming.

Allowing users to abort an operation that’s taking too long, whether it’s because it’s frozen/stuck, or simply taking too long versus the benefit it’s bringing, would go a long way toward improving usability across the board.

“But how will the program know how long it will take? Every computer is different!”

Well, you could have a basic benchmark feature that would run through some tests and “learn” how long YOUR particular machine would take to conduct a certain number of certain operations.

This brings me to another feature / side-benefit: a unified “Sketchup Performance Score” that would allow users to make more informed decisions regarding upgrading their hardware, operating system, graphic drivers, etc.

Which would benefit the Sketchup userbase / ecosystem by creating a cost/benefit basis for hardware upgrades. If a better CPU / GPU combo would yield 500 additional SPS, at a cost of, let’s say $ 50, it’s worth it… if it would only yield an extra 25 SPS, it’s not.

Currently, there’s no way to objectively benchmark the monetary value of hardware upgrades for this specific software. With a unified benchmark score - there would be.

Hardware vendors would love it because it’s an additional selling point (“our videocards outperform the other guys in Sketchup by 18% for the same money!”)

Trimble should love it because it’s more market exposure at no additional cost.

Users would love it because it lets them make informed decisions.

(P.S. I’m available for marketing consultations, in case you guys need someone with 20+ years of watching WordPerfect, CorelDRAW, AutoCAD, Illustrator, Photoshop, and other programs develop.)

2

Only if you add emulation for PlayStation and XBox to your list of feature requests. Otherwise I can’t see any video card / hardware maker giving any thought to SketchUp.

Sketchup, like what we put on hamburgers? Ehhh, ¯_(ツ)_/¯ why does my video card need to care about that?

3

Even basic games seem to get Nvidia’s Game Ready optimisations these days.
And sometimes a piece of software doesnt have to be popular to catch the attention of hardware companies. Look at Cinebench or WinRAR or Blender (cycles) as examples of how a good benchmark function within the software could become influential among reviewers depsite the software being reasonably niche.
That said, i doubt SketchUps utilisation of hardware warrrants a useful benchmark tool as it doesnt appear to fully utilise any hardware component.
But i like the idea of a more scientific way of choosing hardware for Sketchup. The current Test Time Display Benchmark doesnt cut it.

4

This is usually said by someone who has no knowledge about the subject. (in this case coding)
I wouldn’t know if these changes are simple as I know nothing about coding, so I wouldn’t say such a thing…

Otherwise I agree with your feature request.

2 Likes
5

That would be great and thanks for sharing, but they are unfortunately not relatively simple changes.

8 years old but still very relevant: Progress Bars are Surprisingly Difficult

The abortable operation is also pretty hard to do well. You need to be able to perfectly roll back all the changes made so far to the model, and ensure that doesn’t take a long time so the user should just have waited for the operation to complete.

2 Likes
6

If you know there’s a possibility of aborting / undoing, it’s actually simple from the software-architecture POV.

You save a state / checkpoint, and then start the operation. If it’s aborted, you unload whatever is in memory and load the checkpoint. If it’s completed (and confirmed by user), you save the new version as the next checkpoint.

Yes, it’s more expensive in terms of memory and storage, but this isn’t 1994, storage is cheap and users’ time is much more valuable.

7

The question of “is it going to take longer to load/unload the checkpoint or to complete the operation” would be resolved by the internal benchmarking - if the program knows it will take 8.2 seconds to load the file, versus 9 minutes to complete the operation, it’s a pretty straightforward call.

Or let the user decide:

“This operation is estimated to take 9 minutes to complete. If aborted, it will take <1 minute to reload the previous state. Proceed? [Yes / No].”

And then it’s not your problem, it’s the user’s.

I don’t know, maybe I’m spoiled by COBOL and Linux, but the general Windows mentality of “it’s gonna take as long as it’s gonna take, buddy, deal with it” irks me… Microsoft’s lackadaisical attitude has a cascade effect on pretty much everything developed under Windows. It’s not even a SketchUp issue, it’s a systemic issue, I’m not blaming you guys.

8

From the “Progress Bars” link:

“still useful, as established by Brad Allan Meyers in his 1985 paper (“The importance of percent-done progress indicators for computer-human interfaces”).”

Exactly what I’m talking about. Even back forty years ago (!!!), software architects understood the value of user awareness of machine processes. I just think that with the massively more powerful hardware we have today, “the edges are smoother” and it should be easier to run estimates.

Maybe it doesn’t have to be a definitive time estimate, fine. But at least a progress bar showing the completed work versus remaining, and percentage, so the user can guesstimate how long it’s taking. This is the approach that Epic Games takes - I can start an update on a game, and it’s not showing a time estimate, but if I see “1-2-3-4-5-6-7-8-9-10%” roll past in a few seconds, I know instinctively it’s going to be a minute. If I see “1%… … … … … 2%”, I know it’s going to be about 5 times slower. But at least I know SOMETHING.

This current situation with “Purge Components” … … ??? … ??? … ??? Nothing’s moving … … ??? … Hmm is it frozen? … … ??? … … I wonder what the weather will be like tomorrow … … … Nope, still frozen … … … … Ok, let’s get some coffee … … … … Still nothing changed … … … Huh … … … … So should I… … … I don’t know, give it another minute … … …" is much more nerve-wracking.

And that’s just the SketchUp internal functions. Doing things like Polyreduce or Cleanup^3 on a complex model could literally take HOURS. (My personal record is 14 hours and change, I have the screenshot somewhere. I knew it was going to take that long, so I just let it run in a separate process. Imagine if you have to sit there and guess at it for 14 hours…)

Just saying. There has to be a way to bring SOME enlightenment of the process to the user interface. And an internal benchmark subsystem is an excellent way to start.

9

Yes we do this already for the undo system.
It’s not going to be just a matter of a handful of lines of code to use it to make all operations abortable though!

1 Like
10

Nobody disputes that this is valuable.
But it’s not simple.

1 Like