A way to avoid that ?

[Didier Bur]

Hi all,
When a script has a bunch of entities to create/draw, after several seconds it shows the hourglass until it finishes its job, then redraws the view entirely. Outputing messages or progressbar doesn't prevent that.
Anyone knows why it does that and if there is a workaround ?

[thomthom]

The work that the Ruby script produces blocks any other operations, including updating the UI.

Fredo uses a timer to split up the work into smaller chunks in order to produce a more responsive UI. I have experimented with the same but found the processing time to multiply many times. Didn't feel the benefit of a responsive UI was worth the extra time.

My test project:
Progressbar Tool Test

TT_Test.test_basepoint # Normal loop. For speed reference.
TT_Test.test_walker(true) # disable UI
TT_Test.test_walker(false)

[Didier Bur]

Thanks TT, so I'm not alone facing this problem

P.S.: first time ever that I see "view.draw2d( GL_QUADS, fill )" working OK. Each time I've used that it always drew the quads in a black color, no matter the drawing color set before !

[thomthom]

@didier bur said:

P.S.: first time ever that I see "view.draw2d( GL_QUADS, fill )" working OK. Each time I've used that it always drew the quads in a black color, no matter the drawing color set before !

view.draw2d has worked with GL_QUADS and the other fill styles.
But view.draw hasn't. That was recently fixed in SU8M1. In addition, view.draw and view.draw2d now makes use of the alpha channel in Sketchup::Color ! That's a very nice fix as it allows for nicer and better UIs.

[thomthom]

@didier bur said:

Thanks TT, so I'm not alone facing this problem

People have tried using threads to offload the work, but due to the nature of threads in SU Ruby 1.8 it doesn't help in our case.
Even doing webdialogs, - but the ruby working blocks even the webdialog.

[TIG]

Completely off the wall idea... and untried
tid=UI.start_timer(0){your_code_here}
So your_code now executes outside of the main Sketchup process - rather like my ImageAnimator does...
If all geometry changes etc were kept inside a group [perhaps hidden] until the end when you can explode it if needed then you shouldn't notice it till it's done ?
Not sure how model.start/commit_operation might work inside of a UI.timer
You could perhaps still report progress through a webdialog progressbar ??

Just ideas [as someone else often says]...

[thomthom]

@tig said:

Completely off the wall idea... and untried
tid=UI.start_timer(0){your_code_here}

The sample I posted above splits the work into timed execution.

@tig said:

So your_code now executes outside of the main Sketchup process

No - it's not outside. It's just delayed. If you add the whole lot of work to be done into one time interval it'll still freeze up the UI.

What Fredo did, and what I tried, was to split the work into smaller chunks which is done by the timer. After each chunk is done, other things are allowed to complete - until the timer triggers again. The trouble is balancing. Evenever the timer chunk doo too much work you'll find the UI freezing again.

[TIG]

@thomthom said:

@tig said:

Completely off the wall idea... and untried
tid=UI.start_timer(0){your_code_here}

The sample I posted above splits the work into timed execution.

@tig said:

So your_code now executes outside of the main Sketchup process

No - it's not outside. It's just delayed. If you add the whole lot of work to be done into one time interval it'll still freeze up the UI.

What Fredo did, and what I tried, was to split the work into smaller chunks which is done by the timer. After each chunk is done, other things are allowed to complete - until the timer triggers again. The trouble is balancing. Evenever the timer chunk doo too much work you'll find the UI freezing again.

Sorry [great minds think alike] I hadn't looked at your or Fredo's code...
You could split the processing into tiny pieces - it's usually iterating lots of values that see to 'whiteout' ?
max=1000;i=0;tid=UI.start_timer(0,true){your_code(i);i+=1;UI.stop_timer(tid)if i==max}
You'd actually set 'max' from the complexity of the actions as in 0.to(max)... The your_code(arg) takes 'arg' and knows which step to execute in the iteration etc... This way an iteration is done using the one timer repeating till it's done - one step at a time - much slower I'd expect but then hopefully 'whiteout' free...

[Jim]

Try to avoid adding individual geometry (add_face) if add_faces_from_mesh() or fill_from_mesh() can be used.

Use model.start_operation/commit_operation and take advantage of the 2nd parameter.

As has been said, you can add geometry while also keeping SketchUp responsive by partitioning the work and adding each partition in a timer block. This will likely make the overall operation even slower, but the user will be able to cancel or even interact with the model while in progress.

Here's an animation I made some time ago showing adding faces in a timer block while allowing interaction with the model.

http://forums.sketchucation.com/viewtopic.php?p=234026#p234026

[thomthom]

Yes - as long as the operations a kept small it'll prevent whiteout. But it can take 3, 4, 5, 6 ... times longer!

[thomthom]

@jim said:

Try to avoid adding individual geometry (add_face) if add_faces_from_mesh() or fill_from_mesh() can be used.

This applies to any SketchUp operation. entities.erase_entities is faster than lots of entity.erase!. entities.transform_entities is faster than individual transformations.
If you have lots of different transformations that only move things around, use Entities.transform_by_vectors. <- even allows you to move vertices.
In Vertex Tools, when you move, rotate and scale, I first run a pass where I transform the position of the vertex, then get the vector from the old position to the new and use Entities.transform_by_vectors. Despite the extra pass it's faster as any method manipulating geometry has a high performance tax so you save lots of time by calling these kind of methods as rarely as you can.

[Dan Rathbun]

@thomthom said:

Yes - as long as the operations a kept small it'll prevent whiteout.

"whiteout" = "ghost window"

@unknownuser said:

(http://msdn.microsoft.com/en-us/library/ms644943(v)":2x9onnad]If a top-level window stops responding to messages for more than several seconds, the system considers the window to be not responding and replaces it with a ghost window that has the same z-order, location, size, and visual attributes. This allows the user to move it, resize it, or even close the application. However, these are the only actions available because the application is actually not responding. When an application is being debugged, the system does not generate a ghost window.

When Sketchup goes into "ghost mode", you will see it listed as "Skethcup (not responding)" in the Task Manager.

First of all, changing the interval that Windows uses to determine when a process is "not responding", although possible, causes other major headaches systemwide. Also, I think that it requires a registry change and reboot (if memory serves me,) so is not a serious option for us.

I would attempt to force a [PeekMessage](http://msdn.microsoft.com/en-us/library/ms644943(v) system call, for Sketchup's thread, within the "responding inteval" (can't remember offhand what it is.)

So any way it's not your add entities block that needs to go inside a UI.start_timer proc, ... it's a API call to PeekMessage, like:

begin
  peek = UI.start_timer(interval, true) {
   peek_window_msg()
  }
  do_create_lots_of_model_entities()
  UI.stop_timer(peek)
end

where, peek_window_msg() would be a method that sets up and makes the proper API call. (It should NOT delete any messages from the queue, basically it is just acknowledging to the system that Sketchup knows that messages are pending to be processed.)

It would be better (for us,) if something like this was built into the main() loop (prodived C++ has something like a start_timer function.) Perhaps John Hauswirth might know if it's possible.

[Dan Rathbun]

The other option, would be to "fool" the system into thinking that Sketchup was being debugged, during the long add entities block.

[thomthom]

Have you used that PeekMessage thing?

[Jim]

That would be awesome if it works.

[Dan Rathbun]

@dan rathbun said:

A debugger object needs to be created and attached to the Sketchup process, etc.

I am wary of releasing anything that does something this drastic.. and because BugSplat! is also likely a (post-mortem) debugger implementation... the last thing I want to do is break the BugSplat! functionality.

[Dan Rathbun]

@thomthom said:

Have you used that PeekMessage thing?

I haven't had time yet myself, (as I have not yet written any code that creates a long Ruby processing delay.)

Also.. it has been a few months since I read that MSDN page, and just noticed the last item about debug mode. (A quick look into this, seems much more complex. A debugger object needs to be created and attached to the Sketchup process, etc.)

[thomthom]

Haaaaaaah!!!!!

Just made a really quick and dirty hack - calling PeekMessage at the inner most loop:

<span class="syntaxdefault"><br />&nbsp;&nbsp;PeekMessage&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">TT</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Win32</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">API</span><span class="syntaxkeyword">.new(</span><span class="syntaxstring">'PeekMessage'&nbsp;</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxstring">'PLIII'</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxstring">'I'</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxstring">'user32'</span><span class="syntaxkeyword">)<br />&nbsp;&nbsp;<br />&nbsp;&nbsp;</span><span class="syntaxdefault">def&nbsp;self</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">refresh<br />&nbsp;&nbsp;&nbsp;&nbsp;msg&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxstring">'&nbsp;'&nbsp;</span><span class="syntaxkeyword">*&nbsp;</span><span class="syntaxdefault">2048<br />&nbsp;&nbsp;&nbsp;&nbsp;r&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">PeekMessage</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">call</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">msg</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">)<br />&nbsp;&nbsp;</span><span class="syntaxdefault">end<br /></span>

worked perfectly!!!!

Though I think one might want to time the peek after a given short enough time. (And msg needs to be of correct size...)

[thomthom]

tried using a timer to sending PeekMessage - while the inner loop did its thing.
didn't work. the inner loop blocked it. So the inner loops need to call this. which means that when SU's methods are processing they will probably block the UI . like intersecting many entities.

But in many cases this can really help.

of course - OSX users are out of luck....

[Jim]

Oh, that's interesting.

Couple a thoughts - terminate the message with a c language null: '\0' (just in case?) The size should still be 2048 including the null.

More obviously, you don't need to peek every loop iteration - so something like:

refresh if (loop_counter % 500 == 0)