Progressbar 2.0
-
you Rock Todd...
-
Care to share some technical insight to how you did this? I've been going through an array of various experiments to achieve a pause-resume progressbar. Closest I got was by using a timer, but that resulted in the whole prosess taking many times longer.
-
Yes, I'm still writing it up. In a nutshell, progressbar is a class that you create an instance of in your tool (nothing new here).
Then, for the new part, you call a new method in progressbar, passing a method reference in your tool, that drives your processing-intensive loop/logic.
Progressbar then performs a callback to your method. Each time your method is called, you'll perform 1 (or "n") iteration of your loop. When you exit your loop and give control back to progressbar, you'll pass the new iteration count to update the progress. Progressbar updates the progress, and calls your method again, and again, and again, until the iteration count reaches the total count you passed when you created the progressbar, and then progressbar returns control to your script, where you can continue processing, start another progressbar, exit, or do whatever.
They'll be other callbacks to your tool for user-initiated events like cancel, stop, start, resume, etc., and you, the developer, will choose what to implement.
That's it - in a nutshell.
-
But how does it allow time for user input, like mouse and keyboard to interrupt? That's always the main problem as a loop locks up the SU UI and all child windows including WebDialogs.
-
Two very key and underutilized methods: #nextFrame and #stop.
Progressbar fills in the blanks that #pause and #resume were supposed to address.
-
Oooh... interesting. And how is the overhead of using the animation class? The timer solution I tried, which was similar concept was just all too slow. http://forums.sketchucation.com/viewtopic.php?f=180&t=34205&p=301000#p300953 I'm not sure why it was so slow, with an interval of 0.
And it's very interesting how you got your script from never ending to run under a minute. Just shows how much the method of processing and iterating means. I've been thinking of trying to introduce some performance challenges where we would take a task and see how people solve it and how fast we could get it. It'd be an interesting way to learn performance tricks from each other as well as maybe picking up a couple of other tricks.
-
Why this works has to be because an Animation runs in its own thread, separate from the thread of the SU UI and Ruby.
It just goes to prove that as we've been screaming for our own (Ruby) thread for 7 years, we really do know why.
There's overhead. Nothing is free. It seems the most overhead is in the Ruby-to-javascript path through execute_script.
I did a sampling of the execution of a do-nothing script to exercise Progressbar 2.0 (merely count to 5000), for a small period of time on my Mac, and the WebCore / Javascript engines in webkit actually appear to be calling compilers and assemblers and linkers internally to prepare the #execute_script calls. Big overhead there. After studying that trace, it convinced me to reduce the traffic between Ruby and Javascript as much as possible, as all those transactions have to be compiled and evaluated. Expensive processing - long code paths. Too bad they can't be cached.
Todd
-
Todd, I'm excited about this one! Looks super awesome. Glad you finally got around to tackling this script. Plus its good to see you are the forums again
Chris
-
@unknownuser said:
There's overhead. Nothing is free. It seems the most overhead is in the Ruby-to-javascript path through execute_script.
A small overhead is acceptable. Timer has too much.
I'll try the animation method with the my old testcase of using a Tool to draw the progressbar. will be interesting to see the times there since it doesn't run through any js or webdialogs. -
Is there a plugin list to know what works with this?
-
@fuzzion said:
Is there a plugin list to know what works with this?
Since Progressbar isn't release yet, the list would be: none
-
@thomthom said:
Since Progressbar isn't release yet, the list would be: none
Wow must of taken ages to compile
-
Took me the wee hours of the night.
-
-
@thomthom said:
Since Progressbar isn't release yet, the list would be: none
That pretty much sums up all progress bars. I just can't bring myself to believe them.
-
are CloseOpens 2.0 and the Progressbar 2.0 out yet??
-
Really exciting stuff! Not since Windows 98 has a progressbar been so anticipated!
-Brodie
Note: I'm not really sure when Windows started having it's little progress bar thing but Windows 98 seemed like the funniest version at the time of writing and I'm too lazy to research it, so I went with it.
-
Progressbar 2.0, as I had wanted to release it, will never see the light of day beyond my computer. Scripts would have to be written to take advantage of it.
I might (might...) release a Progressbar 1.5 though, but it too will require scripts to change (very minimally) to take advantage of a cancel feature.
Todd
(And yes, I've been busy with other projects - namely my day job).
Oh, and expect CloseOpens V2 soon. All that's left is a bit of packaging and final testing.
-
Hi Guys,
I happen to be the "Frenchman" who challenged Todd some time ago which apparently led to progressbar.rbexcept that I am Belgian, from the Flemish part (I am not a fanatic, rest assured !
) but my last sentence will explain the difference for all to understand ! 
I recognise the drawings of my lake
Todd spent some sleepless nights, solved the issue and allowed me to try it out under a gentleman's agreement of confidentiality, which, of course, I respected
still only closeopens v1.1 is available to the general public, which is a pity
lately I have gotten extremely annoyed by the time it takes for sketchup to backup a file
Microsoft Windows's task manager doesn't help either:
invariably it shows that sketchup "does not respond", same goes for Layout:
impossible to know if something is happening, how long it will take,
worse: impossible to intervene without losing part of your dataso Todd, will you please consider taking progressbar.rb to the next level?
or does any of you wizards feel challenged to make one for the backups of Sketchup and Layout ?
I offer a crate of the best Belgian Beer !
thanks, Frank
-
Hi Frank.
First, thank you so much for working with me and having a great test case from which I was able to "fix" closeopens to work more efficiently.
As I rewrote closeopens, the first step, as you know, was to modify progressbar to allow the user to choose to cancel the process. After I did that, I went to rewrite the algorithm used by closeopens to make it MUCH more efficient. IIRC, the processing time for your model went from INFINITY (as in, it never did finish) to 52 seconds.
I was excited about modifying progressbar to make it V2, and have it apply globally to all the scripts that used it, but I was not able to crack that nut without also having a requirement to also modify each and every script that called it to allow the canceling of the process. This is where Progressbar 2.0 died.
However, closeopens does have Progressbar 2.0 functionality built-in, and, I have stalled bring closeopens to market, for some time now. And, while some attempts have been made by me to get it ready for packaging, I have broken the new copy. This is where I stand. I need to fix it, again, and then publish it. I will do this - but cannot promise when right now. My day job is demanding, and so are extra-curricular activities.
Todd
Advertisement