[Webdialog] freeze during Ruby operation

jolran

The question is related to this old thread, and I wonder if the issue is still the same ?

http://sketchucation.com/forums/viewtopic.php?f=180&t=17595&hilit=webdialog+freeze&start=30

WebDialog stops when Ruby runs

This is quite disturbing when dealing with interactive webdialog that need to execute larger ruby operations.

It's the first thread about this problem I've found so maybe this problem is already solved.

AdamB wrote:
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.

Chris Fullmer

Nope, not fixed. I have not seen any way around it at this point.

jolran

Thanks for answering, Chris.

Total showstoper

I was working on separating Ruby updates from javascript when I noticed I did not
get any difference/timing in the HTML..

That means that webdialogs can only "practically" be used as forms with SUBMIT behavior, I suppose..

Sighs...

tt_su

What kind of operations do you need to do? Calculations?

jolran

Well, Think Grasshopper GUI sort of thing for a minute. (Any parametric modeler GUI would be applicable.)

Sketchup would need to give some visual feedback during changes in the HTML.
I use drawing transient geometry through a tool's class draw method.

I suppose I could refactor and/or simplify the way I currently draw "viritual" geometry, but only to a certain extent. The update methods still must run and do it's calculations to produce the output.

The wait would off course be the same even if the HTML did not freeze.
BUT, I do Believe the user would not experience the wait as long during RUBY updates if one could navigate the HTML and/or get some progress feedback.

Luckily I have implemented the ability to disable preview for each node, but normally the end Product will be the most geometric dense.

I think I'll have to simplify the visual geometry a little. That's the only solution I can come up with.
But all in all, the freezing behavior would be very annoying for the user.

tt_su

Have you profiles your code and found what consumes the most time?

jolran

A little bit, but not systematically. There's room for improvements for sure

It certainly looks like it's the draw class taking time to build OPEN GL geom.
One indication is that when I disable preview everything runs pretty fast and smooth but the containers(arrays and hashes) holding the data for the draw class are still there.
First I thought the Garbage collector was having it's saying in this, cause I'm clearing a lot of data through updates (which happends frequently). But now I doubt that is the main issue. Could still be though, not sure..

I have to try to pinpoint this down in a different approach. I doubt though one can display dense OPEN GL preview fast in Sketchup. So might have to rethink my design a bit.
How Heavy geometry does your render cache work fine with ?

tt_su

Draw "class"? or did you mean method?
Are you calculating the draw data in the draw method itself? If you are, then I'd recommend you cache it and rebuild the cache only when the data changes.

I created a cache class for this: https://bitbucket.org/thomthom/tt-library-2/src/2bb264f27d9bc00c1b1f9a969e481c19385042ad/TT_Lib2/draw_cache.rb?at=Version%202.9

jolran

Draw method, in a tool. Sorry, my misstake.

Calculations for nodes are done outside the tool class. Passing through those methods
I collect information to be sent to a container that the Tools draw method fetches
information for rendering. I have a bit of work left there to get things organized.

The data changes constantly so it will probably cost more to iterate what is needed to be updated then to redraw everything in 1 go.
Since mostly dealing with Points and vectors, the new data will probably be totally different then the old anyway.
I just clear the old data and bring in new, sort of, without going into details..

There are different types of data though. Persistent data that references to a Sketchup entity for ex, can be cached and updated only when switched.

Anyway got a new situation now(TOPIC), have to redesign a lot on the Ruby side.

I've studied your render cache. It's very nice and good example. Need to study it more though.

Thanks for the input