feat: Modify the next frame delay method by changing setTimeout to re…

[Planck-Ho]

…questAnimationFrame #856

Modify the next frame delay method by changing setTimeout to requestAnimationFrame

Description

Checklist

• The web version was tested and it is running ok
• The desktop version was tested and it is running ok
• This change is covered by unit tests
• Files constants.ts, types.ts and *.style.ts have been checked and relevant code snippets have been relocated

[rodrigo-rodrigues-ctw]

Hi @Planck-Ho
We'll take a look in the near future.
Thanks for the contribution!

[ctw-joao-luis]

Hey @Planck-Ho first of all thank you for your contribution, while testing this change I noticed that this change affected by a considerable amount performance on some use cases. I think the do while loop logic is waiting multiple times per frame causing this issue.

I dont know if it will fix it, but you can try to remove the do while condition or use a single requestAnimationFrame per tick without the loop, I think the condition check might be causing redundant waiting that kills performance.

Also rebase your branch with develop and fix conflicts.

Cheers,
JL

[Planck-Ho]

Hey @Planck-Ho first of all thank you for your contribution, while testing this change I noticed that this change affected by a considerable amount performance on some use cases. I think the do while loop logic is waiting multiple times per frame causing this issue.

I dont know if it will fix it, but you can try to remove the do while condition or use a single requestAnimationFrame per tick without the loop, I think the condition check might be causing redundant waiting that kills performance.

Also rebase your branch with develop and fix conflicts.

Cheers, JL

Perhaps under high refresh rate displays, requestAnimationFrame may be greater than 60Hz

[ctw-joao-luis]

Thanks for the explanation your reasoning around requestAnimationFrame on higher refresh rates displays is valid and we appreciate the thought behind it.

However, after testing this internally we found that certain use cases, as I stated, take a performance hit with this change. The do-while loop iterating multiple times per tick ends up introducing overhead that outweighs the benefits in our current setup, so unfortunately we can't merge this right now.

We'll keep the idea in mind as something to revisit down the line. Thanks again for the contribution!

Cheers,
JL