GUACAMOLE-377: Address performance regression related to migration to guac_display. #1045
Conversation
The asynchronous flush mechanism leveraging requestAnimationFrame() does not perform as well as the old synchronous flush. This appears to be due to delays in when the browser actually allows the frame to proceed, causing the client to lag behind. The old synchronous flush mechanism does not suffer from such issues.
mike-jumper
changed the title
|
I've added some additional changes here that should significantly help with latency. By using the new |
|
Additionally, another future improvement is use of OffscreenCanvas with a Worker |
There was a problem hiding this comment.
@mike-jumper - I'm good with it. Not sure if there's anything that @DanielMcAssey mentioned that's worth addressing, or if you want to keep it as-is?
|
I think it's find to keep as-is. I've been experimenting with using a WebWorker for rendering (and, implicitly, OffscreenCanvas), but I don't think there's any need to hold off on these improvements. If the WebWorker approach does improve things further, I think it's OK for those improvements to be after 1.6.0. The current approach is already significantly faster. |
This partly reverts the changes introduced by d6db8fa (#681), restoring the previous client-side frame handling.
The new asynchronous flush mechanism leveraging
requestAnimationFrame()does not perform as well as the old synchronous flush. This appears to be due to delays in when the browser actually allows the frame to proceed, which cause the client to lag behind.A future change that could improve things further might be to process graphical changes in a WebWorker when available.