Re: Plotting question

[Douglas Eck]

According to the gnuplot.ps manual, replot
isn't the best way to refresh a multiplot:
  "Note that replot doesn't work in multiplot mode since
  it reproduces only the last plot rather than the entire screen".

So I stopped using "replot". When I do my loop like this, it is fast:
for i=1:100
    subplot(1,2,1);
    gset('multiplot')  %%<-- the important line
    plot(rand(1,10),'r')
    subplot(1,2,2);
    plot(rand(1,10),'b');
end 

However, the second subplot flickers because the whole
subplot, including axes, is getting redrawn as a byproduct
of the gset('multiplot')

If I comment out the "gset('multiplot') then the flickering 
goes away, but the screen does not clear, so I see all my
previous plot (as in "hold on")

I can get rid of the flickering and the multiple lines by
using "replot" (see original code) but then it's slow. 
Using replot like this is slow even in gnuplot directly,
so it's clearly not an octave bug. Just a stupid thing
to do. Stupid and pretty.

Anyway, this was *really* slowing down my code, so I thought
I'd post back my little fix of setting multiplot. Now it's
flickery but faster. 

As an aside, when I take the cat output from the code above
and run it directly in gnuplot, *there is no flicker*. 
So somehow the flickering seems to be a product of
octave / gnuplot interaction (though not necessarily
an octave bug of course.) Perhaps someone has an idea?

Cheers,
Doug



> |
> | Here's a sample of what I mean. With this code snippet, the
> | gnuplot x program can't seem to keep up:
> |
> | for i=1:1000
> |   subplot(1,2,1)
> |   plot(rand(1,10),'r')
> |   replot
> |
> |   subplot(1,2,2)
> |   plot(rand(1,10),'b')
> |   replot
> | end
> |
> | But without subplots, things seem to work just fine.
> | for i=1:1000
> |   plot(rand(1,10),'b')
> |   hold on
> |   plot(rand(1,10),'r')
> |   hold off
> |   replot
> | end
> |
> | Anything obvious I'm missing?
> |
> | PS I'm running Dirk's Debain 2.1.32 build on Debian Sid.
> 
> I don't know why gnuplot behaves this way.  I don't think it is a
> bug in Octave.  After doing some simple debugging by putting a print
> statement in your loop and looking at what Octave is sending to
> gnuplot (by setting gnuplot_binary to "cat") I don't see anything
> unusual in what Octave is doing, and Octave gets way ahead of gnuplot.
> 
> If anyone can show how the problem is with Octave, then please let me
> know.  Otherwise, can someone please try to find a test case that
> demonstrates the bug in gnuplot and then report the problem to the
> gnuplot maintainers?
> 
> Thanks,
> 
> jwe
> 
> -------------------------------------------------------------
> Octave is freely available under the terms of the GNU GPL.
> 
> Octave's home on the web:  http://www.octave.org
> How to fund new projects:  http://www.octave.org/funding.html
> Subscription information:  http://www.octave.org/archive.html
> -------------------------------------------------------------

-- 
Dr. Douglas Eck, http://www.idsia.ch/~doug
Istituto Dalle Molle di Studi sull'Intelligenza Artificiale (IDSIA)
Neural Networks, Rhythm Perception and Production, Dynamical Systems



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------