Timeline efficiency

Colzie

I have a timeline that, at various times, I need to run through one time. Which is the more processor efficient way to handle this?

OPTION A:
Every time I need the timeline to run, kill it if it is running, then use TIMELINE_CREATE with the TIMELINE_ONCE parameter.

OR

OPTION B:
Create the timeline once with the TIMELINE_REPEAT parameter. Pause the timeline when I don't need it. When I do need it to run, use TIMELINE_SET to 0, and restart the timeline, pausing after it runs through one time.

I am using the timeline to refresh dynamic images that the user can cycle through, so I may not need the timeline for a long time (which makes me lean to Option A). When I do need it, it will probably be used repeatedly while the user pages through the images (which makes me lean to Option .

??

ericmedley

Option A. A paused timeline is still using resources.

Colzie

With Option A, when the user touches "Page Down" 10 times in 2 seconds, the timeline will be created and destroyed a lot of times very quickly. Performance should still be okay? I'm not familiar with what timeline_create actually does behind the scenes.

yuri

why do you need a timeline?
If you need it to refresh a dynamic image, there is no need to use a timeline

ondrovic

I agree with yuri just make a call or function to update the dynamic images when the page is changed

Colzie

I am using the timeline to space out the RMF commands to the panel.

Here is (some of) the relevant code:

define_variable

volatile long l_tl_icons[] = {400, 400, 400, 400, 400, 400, 400, 400}

define_event

data_event[dv_MASTER]
{
	online:
	{
		timeline_create (TL_ICONS, l_tl_icons, length_array (l_tl_icons), TIMELINE_RELATIVE, TIMELINE_REPEAT)	
	}
}


timeline_event[TL_ICONS]
{
	stack_var integer i, iOffset;
	
	i = timeline.sequence
	iOffset	= fn_get_offset ()
	
	send_command dv_TPs, "'^RMF-FAV', itoa (i), ',%F', u_db[i + iOffset].s_icon"
}

Greg

Instead of using the push put it on the release with a named wait. On a push event stop the wait. It'd add a little latency, but keep it from flooding.

button_event[dvTP, nSomething]
{
push:
{
cancel_wait "DoSomething"
}
release:
{
wait 5 "DoSomething"
{
// Something
}
}
}