[R] animation without intermediate files?
bogdan romocea
br44114 at yahoo.com
Wed Jan 26 21:59:26 CET 2005
Here's a different suggestion. Create a bunch of image files, and then
use an image browser (GQview is one of the best; if you're on Win look
at ACDSee) to view them as a slide show. Good image browsers read
images in advance and should not produce flickering. I haven't
experimented though with delays under 5 seconds.
HTH,
b.
-----Original Message-----
From: Paul Murrell
Sent: Wednesday, January 26, 2005 2:46 PM
To: Martin Maechler
Cc: Cari G Kaufman; r-help at stat.math.ethz.ch
Subject: Re: [R] animation without intermediate files?
Hi
Martin Maechler wrote:
>>>>>>"MM" == Martin Maechler <maechler at stat.math.ethz.ch>
>>>>>> on Tue, 25 Jan 2005 09:59:03 +0100 writes:
>>>>>
>
>>>>>>"Paul" == Paul Murrell <p.murrell at auckland.ac.nz>
>>>>>> on Tue, 25 Jan 2005 13:40:15 +1300 writes:
>>>>>
>
> Paul> Hi
> Paul> Cari G Kaufman wrote:
> >>> Hello,
> >>>
> >>> Does anyone know how to make "movies" in R by making a
> >>> sequence of plots? I'd like to animate a long
> >>> trajectory for exploratory purposes only, without
> >>> creating a bunch of image files and then using another
> >>> program to string them together. In Splus I would do
> >>> this using double.buffer() to eliminate the flickering
> >>> caused by replotting. For instance, with a 2-D
> >>> trajectory in vectors x and y I would use the following:
> >>>
> >>> motif()
> >>> double.buffer("back")
> >>> for (i in 1:length(x)) {
> >>> plot(x[i], y[i], xlim=range(x), ylim=range(y))
> >>> double.buffer("copy")
> >>> }
> >>> double.buffer("front")
> >>>
> >>> I haven't found an equivalent function to double.buffer in R.
I tried
> >>> playing around with dev.set() and dev.copy() but so far with
no success
> >>> (still flickers).
>
> Paul> Double buffering is only currently an option on the
Windows graphics
> Paul> device (and there it is "on" by default). So something
like ...
>
> Paul> x <- rnorm(100)
> Paul> for (i in 1:100)
> Paul> plot(1:i, x[1:i], xlim=c(0, 100), ylim=c(-4, 4),
pch=16, cex=2)
>
> Paul> is already "smooth"
>
> MM> well, sorry Paul, but not for my definition of "smooth"!
>
> MM> Instead,
>
> MM> n <- 100
> MM> plot(1,1, xlim=c(0,n), ylim=c(-4,4), type="n")
> MM> x <- rnorm(n)
> MM> for (i in 1:n) { points(i, x[i], pch=16, cex=2);
Sys.sleep(0.02) }
>
> MM> comes much closer to my version of "smooth" ;-)
>
> I apologize to Paul, since what I said seems to be quite
> platform dependent. Here's my current "knowledge" on the matter:
>
> o Paul's " for(..) plot(..) "
> - flickers quite a bit for me {on Linux X11 with no
> particularly fast graphics card}.
> - seems quite smooth for at least two Windows users who have
> relatively fast graphics cards.
>
> o My solution of
> " for(..) { points(..) ; Sys.sleep(..) } "
> doesn't redraw the coordinate system and so doesn't "flicker"
> (afaik, independently of platform)
>
> HOWEVER on windows; the graphics are somehow buffered and
> points are not drawn one by one, but rather in batches --> "not
smooth"
Thanks Martin; I wasn't very clear on my original message. Double
buffering has only been implemented on the Windows graphics device at
this stage (thanks to Brian) and this implementation basically always
writes to a buffer and updates the screen at fixed time intervals
(quoting the source: "100ms after last plotting call or 500ms after
last
update") so there is no user control of when the off-screen buffer is
swapped to the screen.
For "animating" a plot where only new output is added (i.e., no
existing
output is modified or removed), your suggestion should produce the
smoothest result.
Paul
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
paul at stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
______________________________________________
R-help at stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide!
http://www.R-project.org/posting-guide.html
More information about the R-help
mailing list