A way to avoid that ?

[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)

[thomthom]

@jim said:

Couple a thoughts - terminate the message with a c language null: '\0' (just in case?)

Isn't that just for strings?
The string I pass is just a data buffer that will be filled with binary data - which one has to extract.

@jim said:

More obviously, you don't need to peek every loop iteration - so something like:
refresh if (loop_counter % 500 == 0)

Yes - more pragmatic than calculating time. I like it, it's KISS.

[Jim]

@thomthom said:

Isn't that just for strings?

Yeah, I made an assumption the message was a c character array.

[thomthom]

@jim said:

@thomthom said:

Isn't that just for strings?

Yeah, I made an assumption the message was a c character array.

No, it's a MSG structure. Just didn't bother to work out exactly how large it is. (probably will be making a wrapper for this.) So I just make a large buffer while I quickly tested it.
...if I don't need the returned message, would it be ok to just send an empty buffer?

[Dan Rathbun]

@dan rathbun said:

@thomthom said:

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

"whiteout" = "ghost window"

...[snip]...

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.

@ThomThom & friends, ... I stumbled across where I saw the 'whiteout' interval.
It's specified on the [IsHungAppWindow](http://msdn.microsoft.com/en-us/library/ms633526(v) Function reference page.
Says 5 seconds.

So perhaps:

begin
  interval =( Sketchup.version.to_i<8 ? 4 ; 4.9 )
  peek = UI.start_timer(interval, true) {
   peek_window_msg()
  }
  do_create_lots_of_model_entities()
  UI.stop_timer(peek)
end