#2834 Multiplot flicker on redraw

[Wojciech Graj]

Attempting to display an animated multiplot causes flickering when the plots are redrawn. The behavior is consistent across terminals (wxt, x11, qt). I am using gnuplot 6.0 patchlevel 2 on Linux.

The flickering gets worse the further the plot is from the top-left corner, leading me to believe that the plots get drawn one-by-one, and the output isn't being buffered.

See the minimal example below. I have also attached a screen recording showing the behavior.

set term wxt  # or x11 or qt

do for [t=0:50] {
    set multiplot layout 3,3

    set yrange [-1.5:1.5]
    plot sin(x + t) with lines t ""
    plot cos(x + t) with lines t ""
    plot sin(x - t) with lines t ""
    plot cos(x - t) with lines t ""
    plot sin(x + t*0.5) with lines t ""
    plot cos(x + t*0.5) with lines t ""
    plot sin(x - t*0.5) with lines t ""
    plot cos(x - t*0.5) with lines t ""
    plot sin(x) with lines t ""

    unset multiplot

    pause 1
}

[Ethan Merritt]

Umm, yes? That's the way multiplot works. The component plots are drawn one by one. When you "replot", the sequence of commands that drew them one-by-one is replayed.

[Wojciech Graj]

Fair enough. As a new feature, I imagine it could be a useful to allow the whole frame to be buffered in an interactive terminal, to allow for plotting live data.

[SiegeLord]

What is requested here is double buffering, which apparently already exists on the windows terminal (judging by https://sourceforge.net/p/gnuplot/patches/526/). In fact I tried it with that terminal, and there's no flickering observed. It could be it's just a faster terminal, I didn't look into the source. So, overall, I think what this is a specific request for one of the terminals (qt I guess?)

[Ethan Merritt]

I don't know anything about the windows terminal, but the other interactive terminals (x11 qt wxt) are not based on a bitmap representation that could be buffered. Gnuplot sends vector, area-fill, and text requests, essentially drawing brush strokes onto the current canvas. The graphics subsystems on the other end of those requests maintain a display list of those commands and re-executes them if needed. Of course the display manager (xwayland or plasma or gnome or whatever) may choose to buffer a bitmap representation to allow the window to be moved/covered/uncovered without reexecuting the display list, but gnuplot doesn't know anything about that, and anyway it wouldn't help if the content of the window is changing as it is in this case.

The closest I can think of to what you are asking for might be to use the kitty terminal, which draws the graph as a bitmap image back into the console terminal window rather than into a separate window controlled by qt/x11/gtk. This of course requires that your console terminal supports the kitty protocol (e.g. the KDE konsole terminal). This isn't fully interactive since you can't you the mouse, but the resolution and graphics quality is essentially the same as the wxt terminal since they both use cairo for the graphics.

If the goal were to create an output file containing a smooth animation, gnuplot can do that. You would either choose a bitmap output terminal like png and then postprocess the individual frames to make the animation, or choose the webp terminal to create an animation file as you go. You would then be able to play back the animated sequence using mplayer, vwebp, vlc or whatever and get the benefit of whatever clever buffering or smoothing that player offers. But the request above was for a way to view "live data" so I take it that producing an animation for later viewing is not what is wanted.

Having said all that, the ability to redraw a multiplot in gnuplot is brand new in version 6 and still being worked on. I don't rule out the possibility that something clever might be done to optimize the display if extra information is available. For example if there are four panels in the multiplot and it were known that only one of them has changed, the program might be able to leave 3/4 of the display untouched and only write an updated version to 1/4 of the area. That would potentially eliminate flicker in the unchanged portions of the display. I am open to suggestions for other possible options or cleverness as to how it works.

[Bastian Märkisch]

FWIW, the windows terminal internally draws to a bitmap first, and only blits it to the screen once the plot is complete. This avoids the flicker and does not slow down operations since it is still accelerated by the GPU. Such a scheme should be possible to implement for qt and wxt, too.