Webdialogs for SketchUp ......RIP!
-
@jolran said:
Many thanks for the valuable information, really
And the link too, much appreciated.Looks like you know what youre talking about.
I'm probably not gonna dig into this just yet. Maybe if I reach a dead end with the Webdialog class.
I wan't to build an opinion if it's worth the effort first.
I reached the dead end a year ago, when I implemented heavy optimization operations. I tried ruby thread, which is a fake in ruby 1.8. It did not solve my problem so I looked into c++ and than realize the extension can be compiled with /clr that opens the door to the wide .NET world. -
Aha, interesting. Will chew on it a little..
My brother is a .net developper with quite a bit of knowledge of C++, so I could probably get a big kickstart and set up. Otherwise I woulden't even consider trying..
Anyway, thanks again! I'll keep an eye on you projects
-
@jolran said:
Aha, interesting. Will chew on it a little..
My brother is a .net developper with quite a bit of knowledge of C++, so I could probably get a big kickstart and set up. Otherwise I woulden't even consider trying..
Anyway, thanks again! I'll keep an eye on you projects
Actually you can still use WebDialog without being frozen by heavy operations. The way is similar. Just put all the heavy operations to a new thread that started in the c++ code. The trick part is communication between threads (that's the point I started to look into .net, since it is much easier to handle multithreading thing with .net libraries ).
-
That doesent confuse me less
About threads, I was under the impression Sketchup threads was a bit shaky ? Although I can't really tell the outcome from this topic.
http://sketchucation.com/forums/viewtopic.php?f=180&t=51701&p=467287&hilit=threads#p467287
-
@jolran said:
That doesent confuse me less
About threads, I was under the impression Sketchup threads was a bit shaky ? Although I can't really tell the outcome from this topic.
http://sketchucation.com/forums/viewtopic.php?f=180&t=51701&p=467287&hilit=threads#p467287
Sorry, I can not see the post:
"The requested topic does not exist."The issue for thread is that, Sketchup uses ruby version 1.8.6 (1.8.5 on mac), which does not implement native threads. It means they are not actually "parallel", only one thread is actually running at once, ruby controls the switch. I once tried to open a new thread in ruby to do the operation and check if the operation has finished within a loop in another thread. However the result is not reliable. One can not tell when it does the checks.
In my case my operations are independent from Sketchup. So when open it in another thread in c/c++ it does not freeze the webdialog. If the operations are Sketchup things, e.g. drawing, modification, etc. it will not help. In that case it's better to have the GUI in a new thread different from the ruby thread.
-
Strange I don't seam to be able to paste the link properly. Never mind. The topic was called UI.timer or something like that.
From what I understand the outcome from that topic was about the same as you says.
I think I misstook c++ threads for Ruby threads. You could probably say anything regarding C code, and I believe it..
-
@icehuli said:
I think the same method can be applied for c++ gui, e.g. qt, as well. A new thread need to start for the GUI to avoid it being frozen while ruby scripts are being evaluated.
Isn't the work being done in the work being done in the new thread while the main thread remains control over the UI?
(Though this would not work in SU if the "work" is manipulating entities.)
-
@jolran said:
Strange I don't seam to be able to paste the link properly. Never mind. The topic was called UI.timer or something like that.
From what I understand the outcome from that topic was about the same as you says.
http://sketchucation.com/forums/viewtopic.php?f=180&t=51701
People has been using timers to manually slicing up work that interact with the SketchUp Ruby API. It makes the total process take longer, but you can cancel the operation IF you manage the slice it down small enough.
Though I'm not so sure how much gain you'll get in the long run.
If it's calculations being done then I'd recommend you do that in C threads if you are able to. Though, it might run so fast in C that you might need to fiddle with threads and the possible horrors of deadlocks and race conditions. When I ported Vertex Tools' soft-selection calculations to C it ran hundreds of times faster than the ruby version - no need for threading.
-
Note that is is possible some times to get big improvements in just pure Ruby by doing a thing differently. I've found some tasks to take seconds instead of minutes just by working my way around Ruby's bottleneck. (Often it's reusing objects and cache calculations/results with Hashes.)
-
@thomthom said:
@icehuli said:
I think the same method can be applied for c++ gui, e.g. qt, as well. A new thread need to start for the GUI to avoid it being frozen while ruby scripts are being evaluated.
Isn't the work being done in the work being done in the new thread while the main thread remains control over the UI?
(Though this would not work in SU if the "work" is manipulating entities.)
The idea is to control the UI in a separate thread, so no matter what operation is being processed in the main thread or another thread the UI will not be frozen.
-
I checked your extensions to invoker c#from ruby at https://github.com/icehuli/suWpfExt.
I used to use win32ole to invoke my c# extensions. But since SU2014 and ruby 2.0I could not get anything up and running yet, either icehuli extension or my win32ole calls...
Advertisement