Optimize VNC screen update to reduce delays

[ndsl7109256]

Previously, the VNC renderer fed the damaged region to the buffer line by line, resulting in significant rendering delays due to frequent buffer updates.

The implementation has been optimized to aggregate all updates during the current screen refresh cycle. The buffer is now updated once per refresh with the complete damaged region, reducing rendering delays and preventing screen tearing.

Previously

Screen.Recording.2024-12-24.160010.mp4

After optimizing

Screen.Recording.2024-12-24.160117.mp4

Comparing

The table compares the performance of screen updating measuring with GIFs with significant vertical variations(Selected to better illustrate the delay caused by line-by-line buffer updates) , before and after optimization, measured in average execution time (ms). Numbers in parentheses represent the standard deviation (std).

GIF size	Before	After
128x128	4.049ms(3.363ms)	1.928ms(1.424 ms)
256x256	15.797ms(11.030ms)	2.196ms(1.064 ms)
512x512	52.259ms(30.524 ms)	2.379ms(1.138 ms)

Close #81

[jserv]

Thank @ndsl7109256 for contributing!

[huaxinliao]

I am curious whether the experimental data in Comparing was generated with the assistance of other tools.

[ndsl7109256]

I first used gprof to check the hotspot of the VNC backend and found that _twin_vnc_work takes a significant amount of time.
Then, I measure how long _twin_vnc_work takes directly using 10-second samples.

+ clock_t start = clock();
twin_screen_t *screen = SCREEN(closure);
if (twin_screen_damaged(screen))
    twin_screen_update(screen);
+ clock_t end = clock();

[jserv]

I first used gprof to check the hotspot of the VNC backend and found that _twin_vnc_work takes a significant amount of time. Then, I measure how long _twin_vnc_work takes directly using 10-second samples.

uftrace is useful, tool.