Bug 5611 - Double buffering for Web Access
Summary: Double buffering for Web Access
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.8.0
Assignee: Samuel Mannehed
URL:
Keywords: hean01_tester, relnotes, upstream
Depends on:
Blocks: 5605 5610 6132 6138
  Show dependency treegraph
 
Reported: 2015-08-20 11:49 CEST by Samuel Mannehed
Modified: 2017-04-20 11:00 CEST (History)
2 users (show)

See Also:
Acceptance Criteria:


Attachments

Description Samuel Mannehed cendio 2015-08-20 11:49:14 CEST
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
Comment 1 Samuel Mannehed cendio 2015-08-20 11:52:23 CEST
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
Comment 2 Samuel Mannehed cendio 2016-10-11 15:23:02 CEST
Links to bugs that are made trivial/solved by fixing this: bug 5605 and bug 5610
Comment 3 Samuel Mannehed cendio 2017-01-10 09:59:01 CET
Now available in noVNC upstream.
Comment 4 Samuel Mannehed cendio 2017-01-10 13:27:15 CET
(In reply to comment #3)
> Now available in noVNC upstream.

See https://github.com/novnc/noVNC/pull/699
Comment 6 Pierre Ossman cendio 2017-02-06 14:03:21 CET
Seems to work well.
Comment 7 Henrik Andersson cendio 2017-02-17 09:37:12 CET
> * 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.
Comment 8 Henrik Andersson cendio 2017-02-17 09:37:53 CET
Closing this bug due to it in general is a big enhancment.

Note You need to log in before you can comment on or make changes to this bug.