UI.start_timer Issues

chrisglasier

There's an issue with SU's timers - the interval is rounded down to whole integers. So anything below 1.0 will turn into 0.0 turning the timer into an instant loop.

This not really about onKeyDown but about the assertion that I don't understand. Here is a callback that runs an object animation that seems (at least to me) to contradict it.



@dlg.add_action_callback("move") {|d, p|
		a = p.split(";")
		entityNo =  Integer(a[0])
		model = Sketchup.active_model
        entities = model.active_entities
        entity = entities[entityNo]
		p entity.name
        selection = model.selection
        selection.clear
        selection.add entity
		nr = Integer(a[1])
		incr = Float(a[2]).mm
		int = Float(a[3])		# int = 0.1
		dur = Integer(a[4])		# dur = 5
		model = Sketchup.active_model
		entities = model.active_entities
		entity = entities[entityNo]
		mv = Geom;;Transformation.translation [0,incr,0]
		clock = 0	
		timer = UI.start_timer(int, true) {
		clock += int
		if clock < dur
		entity.transform! mv
		else 
		UI.stop_timer timer
		end
	}

Please tell me if I have missed something fundamental (I lost my sensitivity many years ago).

thomthom


t=Time.now; UI.start_timer(1.5, false) { puts Time.now - t }
12546
1.01

t=Time.now; UI.start_timer(0.5, false) { puts Time.now - t }
12514
0.02

See - the timer does not wait for the full duration - instead round the interval down to a whole number.

Dan Rathbun

@chrisglasier said:

Please tell me if I have missed something fundamental ...

I think your confusion comes from that your using the 1st arg to UI.start_timer for double duty. Your also using it within the block as a iteration increment value. Which is fine, it would control the iteration steps correctly, no matter what the delay was/is for the block to begin execution.
As ThomThom points out, in your case it's actually rounding down to 0.

The API does explain the first arg as:
@unknownuser said:

seconds The time in seconds before your code should be called.

chrisglasier

@thomthom said:


> t=Time.now; UI.start_timer(1.5, false) { puts Time.now - t }
> 12546
> 1.01
> 
> t=Time.now; UI.start_timer(0.5, false) { puts Time.now - t }
> 12514
> 0.02
>

See - the timer does not wait for the full duration - instead round the interval down to a whole number.

Well all I know is I used true (repeat) instead of false and the object moves 50 increments in 5 seconds.

chrisglasier

Thanks I will overnight it (the verb)

Dan Rathbun

@chrisglasier said:

Well all I know is I used true (repeat) instead of false and the object moves 50 increments in 5 seconds.

Of course! But if you changed the first arg to a literal 1.0 (and left the local var int still at 0.1,) then your object would finish moving in about 6 seconds (1 second delay before the loop, and 5 seconds worth of animation time.)

I think you were under the impression that the 1st arg delay would occur at the start of each loop iteration, which is not true. It's ONLY the delay BEFORE the block (which I think Ruby converts internally to a Proc object,) is CALLED.

thomthom

@chrisglasier said:

Well all I know is I used true (repeat) instead of false and the object moves 50 increments in 5 seconds.

Could be that the transformation done inside the timer block slows the iteration down to a point where you're getting a time close to what you expect.

i=0; t=Time.now; x=UI.start_timer(0.5, true) { puts Time.now - t; i+= 1; UI.stop_timer(x) if i == 10 } 19079 0.02 0.03 0.05 0.06 0.08 0.1 0.11 0.13 0.14 0.16

chrisglasier

It looks pretty close - I will check the mm tomorrow.

pig 010.png

pig 011.png

chrisglasier

@thomthom said:

Could be that the transformation done inside the timer block slows the iteration down to a point where you're getting a time close to what you expect.

As this thread title seems to have morphed I want to ask other related questions.

Is the timer different from an array because it does not call the next iteration until the transformation is complete?

I am more concerned about sequence than precise timing. So would multiple transformations suffer/benefit from hardware efficiency equally - i.e. the sequencing will be correct?

Thanks