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.