currentTimeChanged handler blocks interface

Visuals, audio, animation. Blended, not stirred. If LiveCode is part of your rich media production toolbox, this is the forum for you.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Post Reply
ElZitouni
Posts: 33
Joined: Sun Oct 14, 2012 10:43 pm

currentTimeChanged handler blocks interface

Post by ElZitouni » Mon Jul 12, 2021 2:24 am

Hello,
I have a player object in stack "P", without the player's controls showing. Buttons to control the player are in stack "C", where also the present video time is displayed. This is done using a handler for the message currentTimeChanged in stack P, which calls a handler in C to update the time display in C.

When I used this form of the currentTImeChanged handler, my interface got "blocked" in that the engine was so busy handling currentTImeChanged that it didn't have time for anything else. I don't really understand why this happens.

Code: Select all

on currentTimeChanged pNewTime
  vidControl_updateTimeDisplay newTime
end currentTimeChanged

So then I tried to not call the update function each time a frame changed, and did this to my currentTimeChanged handler, which solved the problem -- i basically only update the time sporadically, in the example below when 1000 ms have passed since the last update.

Code: Select all

global gPreviousTimeOfPlayer

on currentTimeChanged pNewTime
  if vid_enoughTimeHasPassed(gPreviousTimeOfPlayer, pNewTIme, 1000) then vidControl_updateTimeDisplay newTime
end currentTimeChanged

Then my client wanted to have the option to play the video at different speeds (i.e., normal speed, 2x, 5x, 10x), and so I coded some buttons to this effect that would set the playRate of the player to either 2, 5, 10 or back to 1. If I set the playRate to >1, then I am back to my original problem -- the interface freezes because again too many time-display update calls are issued form the currentTimeChanged handler.

How do I prevent that the interface freezes thanks to incessant currentTimeChanged calls. Should this even happen?

Thank you for your help,
Olli.

SparkOut
Posts: 2834
Joined: Sun Sep 23, 2007 4:58 pm

Re: currentTimeChanged handler blocks interface

Post by SparkOut » Mon Jul 12, 2021 7:48 am

I haven't tested or even know whether this is relevant, but within a repeat loop it is often necessary to include a line

Code: Select all

wait 0 milliseconds with messages
or perhaps a few extra milliseconds.
This gives the engine a moment to interrupt the tight loop hogging all the processor cycles and give a chance for screen updates and keyboard polling to take place.
It might also help in this scenario, but not sure.

ElZitouni
Posts: 33
Joined: Sun Oct 14, 2012 10:43 pm

Re: currentTimeChanged handler blocks interface

Post by ElZitouni » Mon Jul 12, 2021 1:40 pm

SparkOut wrote:
Mon Jul 12, 2021 7:48 am
I haven't tested or even know whether this is relevant, but within a repeat loop it is often necessary to include a line

Code: Select all

wait 0 milliseconds with messages
or perhaps a few extra milliseconds.
This indeed helped ... and thank you for this suggestion which made it work -- however, it is a bit of a hack, which is fine, just doesn't sit well with me aesthetically.

Doing some experiments, I found out that the number of currentTimeChanged messages more than doubles within the measured 20 second time frame of playing the video if the playRate:=5 compared to playRate:=1. That is odd and I really do not understand why this is the case, no wonder everything freezes. Is this a bug?

Then I thought of another possible solution -- I could load up my video with callbacks so that perhaps every 250 ms or so the player sends a message like "updateTimer". But i assume that when you are playing at higher rate, the video advances so much that several callbacks are issued together (probably that happens with the standard "callback" currentTimeChanged in this case). Anyway, the trick with forcing the engine to a moment of quiet contemplation with the wait command solved the problem.

I am astonished that after all this time, the developers of livecode still do not have found the time to update their video handling. It has never been good. This seems a neglected area. Is there an external anybody knows of that could provide reasonable video handling?

Olli.

SparkOut
Posts: 2834
Joined: Sun Sep 23, 2007 4:58 pm

Re: currentTimeChanged handler blocks interface

Post by SparkOut » Mon Jul 12, 2021 2:08 pm

As a generalisation, I have no answer.
Specifically though, another tack is to only send the update if there isn't already one in the queue:

Code: Select all

on currentTimeChanged pNewTime
   if "vidControl_updateTimeDisplay" is not in the pendingMessages then 
      vidControl_updateTimeDisplay newTime
   end if
   wait 0 milliseconds with messages 
end currentTimeChanged
 
I would still keep the wait, it seems more like a housekeeping thing than a hack to me, but I hear and understand.

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7210
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: currentTimeChanged handler blocks interface

Post by jacque » Mon Jul 12, 2021 4:03 pm

I wouldn't use currentTimeChanged at all. Instead, create a handler that checks the currentTime every few seconds using a send command.

Pseudo code:

Code: Select all

on checkTime
    vidControl_updateTimeDisplay
    send "checkTime" to me in 2 seconds -- adjust timing here
end checkTime
When the video starts, call checkTime to get it going and when it ends, clear the pendingMessages.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

ElZitouni
Posts: 33
Joined: Sun Oct 14, 2012 10:43 pm

Re: currentTimeChanged handler blocks interface

Post by ElZitouni » Mon Jul 12, 2021 4:42 pm

clever. I think that is probably the best solution — thanks!
jacque wrote:
Mon Jul 12, 2021 4:03 pm
Icode]on checkTime
vidControl_updateTimeDisplay
send "checkTime" to me in 2 seconds -- adjust timing here
end checkTime[/code]

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9250
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: currentTimeChanged handler blocks interface

Post by richmond62 » Mon Jul 12, 2021 5:48 pm

it is a bit of a hack, which is fine, just doesn't sit well with me aesthetically
What on earth is this recent 'thing' about 'inelegant' and 'inaesthetic' code?

Of course 'anaesthetic' code is another thing . . . 8)

ElZitouni
Posts: 33
Joined: Sun Oct 14, 2012 10:43 pm

Re: currentTimeChanged handler blocks interface

Post by ElZitouni » Mon Jul 12, 2021 5:52 pm

richmond62 wrote:
Mon Jul 12, 2021 5:48 pm
What on earth is this recent 'thing' about 'inelegant' and 'inaesthetic' code?
Pretty code, elegant solutions, never read Knuth?

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9250
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: currentTimeChanged handler blocks interface

Post by richmond62 » Mon Jul 12, 2021 6:00 pm

No I haven't read 'Knuth'.

When it comes to aesthetics I worry about the front-end that the end-user sees.

"Every professional software developer writes code that works, but there is a silver lining between the code that just works and the code that works well and stands the test of time. A solid design guarantees that bug fixing will be a breeze, because bugs will be where they should be! Put differently, when the architecture is not compromised, the bugs are cheaper to resolve and do not contribute much to the technical debt."

https://towardsdatascience.com/beautifu ... ad8a0c6b19

"code that works well and stands the test of time" doesn't always have to be minimalistic, or 'beautiful', what it does have to do is
work well and be understandable whn someone goes back and has a look at it 25 years later.
Last edited by richmond62 on Mon Jul 12, 2021 6:04 pm, edited 1 time in total.

ElZitouni
Posts: 33
Joined: Sun Oct 14, 2012 10:43 pm

Re: currentTimeChanged handler blocks interface

Post by ElZitouni » Mon Jul 12, 2021 6:04 pm

Doing one does not exclude doing the other.

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9250
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: currentTimeChanged handler blocks interface

Post by richmond62 » Mon Jul 12, 2021 6:06 pm

Doing one does not exclude doing the other.
That is true, but doing one does not presuppose the other either,
and when one is pushed for time the front-end is probably more
important than the exact way the "trick" is performed.

ElZitouni
Posts: 33
Joined: Sun Oct 14, 2012 10:43 pm

Re: currentTimeChanged handler blocks interface

Post by ElZitouni » Mon Jul 12, 2021 6:09 pm

richmond62 wrote:
Mon Jul 12, 2021 6:06 pm
when one is pushed for time the front-end is probably more
important than the exact way the "trick" is performed.
yes, of course. I am not saying what people should or should not do. I didn’t start this part of the discussion. A trick is great, and somertimes the only way to go, but doing it is not my preference, unless i have to, that is all.

PaulDaMacMan
Posts: 616
Joined: Wed Apr 24, 2013 4:53 pm
Contact:

Re: currentTimeChanged handler blocks interface

Post by PaulDaMacMan » Mon Aug 16, 2021 3:26 pm

Yes, what @jacque said is probably the best method so you don't get a message queue that is filled to the brim (and yes there is a limit of 64k) with so many callbacks that basically block everything else from happening.
I wouldn't use currentTimeChanged at all. Instead, create a handler that checks the currentTime every few seconds using a send command.
What using 'send in' or 'wait for' X milliseconds (best to include the 'with messages' clause to help prevent blocking) does is schedules a message with the script engines message queue, allowing the engine time to do other things like polling input or updating the GUI. Sometimes it's useful to flushEvents() and flush the pendingMessages queue as well, like when the user hits a pause or stop button.
My GitHub Repos: https://github.com/PaulMcClernan/
Related YouTube Videos: PlayList

Post Reply

Return to “Multimedia”