www.cendio.com
Bug 5611 - Double buffering for Web Access
: Double buffering for Web Access
Status: CLOSED FIXED
: ThinLinc
Web Access
: trunk
: PC Unknown
: P2 Normal
: 4.8.0
Assigned To:
:
:
:
: 5605 5610 6132 6138
  Show dependency treegraph
 
Reported: 2015-08-20 11:49 by
Modified: 2017-04-20 11:00 (History)


Attachments


Note

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


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

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