Performance drop LC 6.1 --> LC 7.1

[bn]

Hi Oliver,

Not sure though if it would help to lock / unlock the screen every 20 milliseconds.

I don't think that would help, the reason is that lock screen only lasts as long as a handler is running. As soon as a handler finishes the screen unlocks automatically, regardless of the last status of lock screen in the handler.

What would help is to put all screen updates (in your case the coloring of the field and the timecode field) into a "game loop". A game loop is typically used in games with a lot of screen updates that would take a lot of time if done sequentially. In a game loop that runs at a constant speed e.g every 40 milliseconds via send in time you gather all the information for the objects that need an update and all objects are updates by the game loop within a lock screen/unlock srcreen pair. Sounds complicated but it is really not once you get the idea.

Your experimentation shows, that you probably could get there using this technique.
If you to try this I could probably find some references or make a sample stack.

Kind regards
Bernd

[okk]

Thanks Bernd! A game-loop is a new concept to me in LC, but it makes a lot of sense. Although the only "disturbing" slow down in my case came from the controller of the player object which I guess can not be trapped in the game-loop, or can it? The player object in our use case only contains a sound-file, namely the audio of the speech which we try to subtitle. I can therefore live with keeping the player hidden, since I control the audio playback from within the script, but it still concerns me a bit thinking about LiveCode and rich media that visibility of the controller of the player object has such massive impact on performance.

Best
Oliver

[bn]

Hi Oliver,

it still concerns me a bit thinking about LiveCode and rich media that visibility of the controller of the player object has such massive impact on performance.

I _think_ it is because before Livecode used Quicktime for AV control and the player was supplied and run by Quicktime. Now that Quicktime is deprecated by Apple and it was a kluge on Windows anyways and not available on Linux at all Livecode had to write its own controller. Which apparently was hard enough with all the platforms. So I guess part of the slowdown is due to that. On the other side the rework of audio/visual stuff for Livecode is not completed yet. So there is hope for a faster solution. But this will be in LC 8 Series, from what I gather.

In the meantime we have to try to use efficient coding techniques to get the best possible performance. One of my applications relies heavily on Quicktime and AV-stuff. Luckily it is locked in an old version of Livecode and old Hardware

Kind regards
Bernd