4729 buffering implementation in the SWT implementation of the canvas.

[saulhidalgoaular]

Fix #4729

[saulhidalgoaular]

Buffer enabled

Buffer disabled

[IanMayo]

@helenayele - we need to test this is ok in Snail Mode, and that range rings & dynamic shapes work ok.

[helenayele]

In this fix, I its performance is improved see this video :
https://screencast-o-matic.com/watch/cYn2jFwxSW

But @IanMayo can you give me a little detail steps when you say test in Snail mode and also range ring..
Because a little confused since in Snail mode we can't see the track segments so can't test this.

[IanMayo]

Hello @helenayele - sure.

Saul is now double-buffering the image. So, we take a "snapshot" of the plot image, and use that when we do some repaint operations. We only create a new "snapshot" when data changes (or something like that).

So, we need to test that the snapshot doesn't get overwritten (or mangled) when Debrief is doing something dynamic, when lots of things are being repainted. Snail mode and moving range rings are examples of the plot changing, but without making edits to the underlying data.

[helenayele]

Works as expected so approving..

[IanMayo]

I've got an issue. Maybe it's just MACOS:

1. Load mid_flow2b.dpf
2. Fit to window
3. Try to drag the short purple TMA leg
4. The background disappears during the drag operation

[saulhidalgoaular]

This is how it looks with that file on Linux and Windows.
Linux:

Windows:

[IanMayo]

Yes, @saulhidalgoaular - I think we need to use an operating system check to prevent using the double-buffering trick on MACOS.

[helenayele]

In windows, it was working before this fix, and also it works fine in this fix :

[IanMayo]

Helen - do you see a performance improvement in Windows? Is it much slower on develop?

[helenayele]

Yes, in develop it is much slower than the current fix, but still it is not that much fast as it is seen in Saul videos in MS window.
In Current fix , it looks like :

In develop:

[IanMayo]

Have compared performance with/without buffering, under MS Windows. With buffering disabled:

Elapsed:89
Elapsed:84
Elapsed:81
Elapsed:83
Elapsed:79
Elapsed:79
Elapsed:78

Switch buffering on:

Elapsed:19
Elapsed:10
Elapsed:14
Elapsed:8
Elapsed:15
Elapsed:10
Elapsed:14
Elapsed:9

But, there's certainly some other expensive operation going on - since we're not getting 10ms update rates - it feels more like 500ms updates.

[IanMayo]

Ok, I've had a look in YourKit:

It's taking 6 times longer to draw the stacked dots than the plot. Our double-buffering has reduced the smaller operation by about 80%, but the expensive operation is still running.