Currently we don't buffer the entire VNC framebuffer in the HTML5 client, we simply draw the data we get from the server in the canvas. Additionally, the canvas only contains what is shown in the viewport. Thus, on touch devices where clipping mode is enabled there are parts of the screen which isn't stored client-side. I see quite a few advantages to having such a buffer: * Avoid screen-tearing since we can draw the entire on-screen canvas at the same time through copying the contents from the buffer. * If the viewport is smaller than the remote frame buffer we can resize the viewport or use panning (if clipping) and see the new areas without having to wait for an update from the server. * We can get a more robust architecture and avoid bugs like 5605 and 5610. It will also make features like zoom (bug 4665) easier to implement. The disadvantages I can come to think of are: * Rendering will be slightly slower. * It will use a bit more memory on the client. * In the case of a smaller viewport, it could use more bandwidth since we could get updates for things happening outside the viewport which we might or might not draw. Upstream discussion: https://github.com/kanaka/noVNC/issues/518
We could possibly use a second, hidden canvas acting as this buffer. A brief example: http://blog.bob.sh/2012/12/double-buffering-with-html-5-canvas.html
Links to bugs that are made trivial/solved by fixing this: bug 5605 and bug 5610
Now available in noVNC upstream.
(In reply to comment #3) > Now available in noVNC upstream. See https://github.com/novnc/noVNC/pull/699
Seems to work well.
> * Avoid screen-tearing since we can draw the entire on-screen canvas at the same time through copying the contents from the buffer. This is not actually true, first off the "tearing" we had before the double buffer is that one could percive the draw of different block during the frame buffer update. The double buffer does now fix that but there are still a screen tearing in the regarding the blit operation from canvas buffer to the screen which we cant affect. Overall this is an enhancement in perceived video quality. > * If the viewport is smaller than the remote frame buffer we can resize the viewport or use panning (if clipping) and see the new areas without having to wait for an update from the server. This works like a charm > * Rendering will be slightly slower. This is not noticed visually, and I can not see any cost increase in CPU with and without double buffer. > * It will use a bit more memory on the client. I used firefox memory profiler and identified a double memory usage eg x2 framebuffer size. We are talking about rather small memory footprints of the total of what firefox allocates. eg. 5% of the total allocated memory.
Closing this bug due to it in general is a big enhancment.
