Frustrated with rubies
-
@unknownuser said:
bomb.rb took 45 seconds to blow it up while doing it manually took 20 seconds (and by manually i mean - select all/explode which takes care of the groups and then repeating that to handle the components)
Some times, if you have a large model, even selecting multiple items to explode bogs down. But selecting one item one by one completes the task faster than selecting all and exploding. And that's with the overhead of moving the cursor, click(select), rightclick(contextmenu), click(explode).
@unknownuser said:
another thing.. on macs, you get the spinning beach ball during the process so you at least know something is happening..
On XP you have the hourglass in addition to the white screen. On Vista and Windows7 with Aero enabled, the screen doesn't do while and you have just the hourglass. (spinning blue circlethingymajiggy) But in either case, you never know if the script or SU has gone down the drain...
-
Just a note for developers.
I have started looking at wxSU for developing dialogs which ties into the native operating system dialog generation routines. I find Web dialogs a pain having to implement a mixture of ruby and javascript as well as the web page. wxSU is written in ruby so less levels of translation. Dialogs can be flexible with auto resizing of the content. Takes a bit of getting used to though.
Relating to the topic, there is a progress bar dialog in the examples folder "ProgressDialog.RB"
wxSU can be found at http://sourceforge.net/projects/wxsu/
-
@thomthom said:
@unknownuser said:
bomb.rb took 45 seconds to blow it up while doing it manually took 20 seconds (and by manually i mean - select all/explode which takes care of the groups and then repeating that to handle the components)
Some times, if you have a large model, even selecting multiple items to explode bogs down. But selecting one item one by one completes the task faster than selecting all and exploding. And that's with the overhead of moving the cursor, click(select), rightclick(contextmenu), click(explode)
in this case (300+ individual groups/components), i think it would take much longer than either bomb.rb or select all/explode to explode everything one by one..
it does make me curious about what exactly bomb.rb is doing though because it took more than twice the amount of time to explode everything at once compared to doing the groups and components separately... i'm wondering if bomb would be faster if it was set up to do what i did manually.. apparently, if i have groups with components nestled inside, select all will not actually select the components.. only the groups.. exploding the groups first then the components next speeds up the process by 2x+..
regardless, i never have a real .skp with that many groups/components and bomb.rb is an instant process for the models i'm working on.. (well, it does have the confirm dialog that pops up and slows down the process & just like weld.rb, i wish the dialogues wouldn't show up)
-
oh.. and why does the progress bar work well with certain rubies and not others?
joint push/pull for instance has a great progress report. -
@unknownuser said:
in this case (300+ individual groups/components), i think it would take much longer than either bomb.rb or select all/explode to explode everything one by one..
It should. But it seems that it doesn't always happen. Some times SU simply choke.
-
I'm glad to hear that at least the basis for many of my frustrations seems to be a known issue (lack of reliable feedback ie. integrated progress bar), at least among the community.
I'd also be interested in finding out what the SU team's position/thoughts are on this.
-Brodie
-
Yup, some times you just have to go for a cup of tea or two.
-
@thomthom said:
Yup, some times you just have to go for a cup of tea or two.
Preferably chamomile, to soothe the nerves
-
My turn.
progessbar.rb is pretty basic. I wrote it a few years ago to fill a gap of no progress bar at all. However, it was still insufficient in its first incarnation since when SU would freeze up due to intense processing of a Ruby script in a single, synchronous thread. Anytime the SU user interface would need repainting, too bad, because the Ruby script had the thread, and the user interface, unfortunately, does not get serviced. When SU hits this wall, the first thing to go is the SU menu bar, then the whole UI freezes, even the status bar where progressbar.rb makes it updates.
I then changed progressbar.rb to add an estimated completion time. It's my opinion that this change transformed it into more than just a "cool animated bar", and into something that was actually pretty useful, since you now know that the script will take another 5 seconds, or 20 minutes, or whatever, and you can adjust your finger-tapping-on-the-desk to some other activity as needed.
The next phase will be a dialog, similar to what Rick mentioned, that will provide a persistent external dialog that will allow you to cancel the script at any time. This will require programming changes to the invoking script, but it will be a big improvement in long running rubies that you choose to cancel.
Todd
-
Isn't the main issue here that the Sketchup core needs streamlining?
I am not a coder, but to me, it feels like there is too much communication/checking going on while doing any operation.
For instance, having the Outliner panel open kills workflow, not only when using rubies.
Having the material browser or component browser open kills performance as well in many cases.A lot of the slowdowns seem to be related to 'getting the output on screen', creating a bottleneck as everything needs to be processed through the OpenGL mill .
Operations one would expect to be powered by your CPU , suddenly seem to be overruled by (the lack of) GPU power (graphical card).A serious rewriting of the SU core, and perhaps implementing better ways for SU to deal with multiple processes at the same time (multicore adapted software) might produce a faster workflow.
Other 3D modelers are modular based as well using plugins. They seem not to suffer of serious slowdowns though.
-
Brodie,
I couldn't agree more with your original point. As much as some of the simplest ruby scripts have become an absolutely essential part of my SU tool set (Todd Birch's "Renumber Scenes", Matthieu Noblet's "Remove C-G Materials", PurgeAll.rb, cleanup_model.rb among others) I recently loaded almost all of the (free) ruby scripts from the "Must Have Ruby Plugins - Visual Index" thread and some of them are either so complicated, or difficult to get to work or are buggy that I just want rid of them asap. "soapskinbubble.rb" is a prime example- at it's core it's ingenious and ought to be useful to every SU user, but it's bogged down with very short time limits of just a few weeks and a really awful UI which never fails to baffle me on the rare occassion that I feel the need to use it. I've learned how to get it to work twice in the past and just discovered to my shame I've forgotten again! I am in awe of anyone who has the skills, but most of all the generosity to create these scripts for free, but when you need a crash course in programming to get a ruby script to work no wonder users aren't donating!) Other ruby scripts add more and more items to the context menu with submenus and obscure names e.g. "FFD>Make Patch".
As much as it's hard to be critical without naming names, I think in any case the real blame doesn't lie with individual ruby scripters- they are after all producing these amazing little tools for no reason other than to try to make other SU users day's a little easier. Google undoubtedly did a great thing when they built the ruby API into SU allowing end users the ability to customise SU, but I think once we all saw just how many excellent ruby scripts were actually being produced we thought this process would have some feedback built in. Sadly, so far this hasn't been the case. I struggle to think of even one ruby tool which was conceived and programmed by an "amateur" ruby scripter which has been implemented as a real (read: outwith the ruby API) SU tool. That is a very serious error on Google's part IMO, as, as far as end users can see they are no longer investing in the future of SU, but are simply allowing ruby scripters to drag it reluctantly and excrutiatingly slowly forwards while other software forges ahead.
-
@unknownuser said:
My turn.
progessbar.rb is pretty basic. I wrote it a few years ago to fill a gap of no progress bar at all. However, it was still insufficient in its first incarnation since when SU would freeze up due to intense processing of a Ruby script in a single, synchronous thread. Anytime the SU user interface would need repainting, too bad, because the Ruby script had the thread, and the user interface, unfortunately, does not get serviced. When SU hits this wall, the first thing to go is the SU menu bar, then the whole UI freezes, even the status bar where progressbar.rb makes it updates.
I then changed progressbar.rb to add an estimated completion time. It's my opinion that this change transformed it into more than just a "cool animated bar", and into something that was actually pretty useful, since you now know that the script will take another 5 seconds, or 20 minutes, or whatever, and you can adjust your finger-tapping-on-the-desk to some other activity as needed.
The next phase will be a dialog, similar to what Rick mentioned, that will provide a persistent external dialog that will allow you to cancel the script at any time. This will require programming changes to the invoking script, but it will be a big improvement in long running rubies that you choose to cancel.
Todd
Is this already available?
-
Nope, not yet. It would be a welcome addition though!
Chris
-
So I saw this thread and spend half an hour playing with building a WebDialog progress bar.
What I planned to do was have a Javascript driven animated progress bar and a simple call from Ruby to update the percentage.
The html/js is trivial but I came unstuck because the WebDialog stops when Ruby runs. Now I don't understand because I supposed that the browser would be running in separate native thread.
Somebody mentioned they'd experimented earlier with this and failed. Was this the same issue?
Adam
-
@thomthom said:
Yea, it's frustrating when a plugin is doing heavy work and you can't tell if it has hung or not.
But mind you, close the Outliner when you run plugins that does heavy operations. That thing really slows things down. You can often see it flicker like mad.I read somewhere that having the outliner open can be useful, when it stops flickering you know the ruby has finished.
I cant remember which ruby, but I was having constant crashes because I was trying to undo before the operation was complete - being an impatient sob. I tend to forget that I've just asked su to recalculate 10000000000:) faces and edges!
bazps: personally, what I really need is a simple way to organise my rubies, for example like 'bookmarks' in 'firefox', most used at the top etc.
As for frustration, compared to windows updates and getting hassled to constantly upgrade by everybody else, I for one am eternally grateful for the fantastic generorsity of the ruby wizards, even the ones who charge. Eg:Sub divide and smooth, 20 bucks, no worries.
(note to self: must donate to fredo for Freescale, wow!) -
I would strongly recommend NOT having the Outliner open for the sake of using it as a 'progressbar'. It increases the time it takes to complete the task many times. And it's prone to cause crashes.
-
In XP just left-click once on the blue bar at the top of your SU window- it'll turn white until SU or the Ruby Script has finished its task. Hardly a progress bar, but it's better than nothing.
-
As to the original post, and as a Architect that used to program, there was little that I did that was completely with out some kind of anomalty. Bugs can be outside your ability to clean up, especially when they deal with the OS, or the programming language itself. But, because it was my program, and I knew where the problems (most of the time) were and simply avoided them. A user on the other hand would be totally frustrated, thinking that he is entitled to a perfectly running program. And he is, especially if he paid for it. Sometimes the application of a program becomes so complex, that with infrequent use, you forget how to use it. And so on, and so on, and so on.
So, regarding my use of rubies that are written by non-professional programmers: 1) I would use a ruby as a application (withing its limitations), and 2) when there is no other way to do what I am trying to accomplish. If I could write them however, I am sure my opinion would be different.
-
@adamb said:
So I saw this thread and spend half an hour playing with building a WebDialog progress bar.
What I planned to do was have a Javascript driven animated progress bar and a simple call from Ruby to update the percentage.
The html/js is trivial but I came unstuck because the WebDialog stops when Ruby runs. Now I don't understand because I supposed that the browser would be running in separate native thread.
Somebody mentioned they'd experimented earlier with this and failed. Was this the same issue?
Adam
Yes, same issue. Scott Lininger is aware of the problem.
-
Advertisement