[Rd] inconsistency/bug in recordPlot/replayPlot

Paul Murrell paul at stat.auckland.ac.nz
Wed Sep 25 02:32:27 CEST 2013


Hi

Unfortunately, my main advice would be not to rely on recordPlot() 
because it (or at least the underlying display list format) was never 
intended for this sort of thing.  I doubt that helps though :)

I might be able to help more, or look at developing a "transportable 
object class for R graphics", if I had a better understanding of what 
you want to do.  Perhaps off list?

Paul

On 09/24/13 15:31, Gabriel Becker wrote:
> Paul,
>
> Thanks for the response.
>
>
> On Mon, Sep 23, 2013 at 7:43 PM, Paul Murrell <paul at stat.auckland.ac.nz
> <mailto:paul at stat.auckland.ac.nz>> wrote:
>
>     <snip>
>     par(bg="white")
>
>     plot(1:10)
>     recplot = recordPlot()
>     png("bgreplay.png")
>     replayPlot(recplot)
>     dev.off()
>
>     Would that satisfy your use case ?
>
>
> Unfortunately it does not, as my use-case is in a caching/dynamic
> document setting. Thus I am capturing plotting from evaluation of an
> arbitrary piece of code within a series of such evaluations. I cannot be
> guaranteed the code doesn't call dev.off() or explicitly create a new
> device and I wouldn't want to clobber any non-white background set in
> previous code.
>
> I thought putting par(bg="white") after the call to png() (or bg="white"
> in the png call) might work, but it appears that replayPlot is actively
> setting the background to transparent so that didn't fly.
>
> Any other ideas or advice would be appreciated.
> ~G
>
>
>     Paul
>
>
>     On 09/14/13 09:17, Gabriel Becker wrote:
>
>         Hey all,
>
>         I've run accross what seems to be a bug in the recordPlot/replayPlot
>         functionality (or at least the lack of a feature which seems pretty
>         reasonable to expect to be there)
>
>         When drawing to a file-based graphics device (I tested with
>         png()), the
>         file resulting from calling replayPlot on a recordedplot object
>         does not
>         contain an identical image to that captured by the same graphics
>         device
>         when used on the plot that was recorded.
>
>         Reproducible (at least for me on linux) example:
>
>         png("noreplay.png")
>         plot(1:10)
>         dev.off()
>
>         plot(1:10)
>         recplot = recordPlot()
>         png("withreplay.png")
>         replayPlot(recplot)
>         dev.off()
>
>         The resulting png files are attached. You'll notice that the
>         noreplay.png
>         has the expected white background, while withoutreplay.png has no/a
>         transparent background.
>
>         This seems likely to be related to the note in ?dev.print :
>         "
>            Note that these functions copy the _device region_ and not a
>         plot:
>                the background colour of the device surface is part of
>         what is
>                copied.  Most screen devices default to a transparent
>         background,
>                which is probably not what is needed when copying to a
>         device such
>                as ‘png’.
>         "
>
>         Now this may be as intended because it is "not allowed" to draw
>         recordedplot objects to devices other than the one they were
>         recorded on
>         (AFAIK the primary purpose of recordedplot objects is fast redraws
>         internally), but alas that is what my use-case calls for.
>         Furthermore,  I
>         don't think I'm alone in thinking wistfully about how useful it
>         would be to
>         have an actual, transportable object class which can fully
>         represent an R
>         plot in any R-based context.
>
>         I'm pretty sure I can compile a patch which does this if it would be
>         considered, though there would be a delay of a week or two
>         before I could
>         burrow out from under the mound of other stuff I currently need
>         to be doing
>
>         sessionInfo below, and I have also confirmed that the behavior
>         remains
>         unchanged in the current trunk.
>
>         Thanks,
>         ~G
>
>             sessionInfo()
>
>         R version 3.0.1 (2013-05-16)
>         Platform: x86_64-pc-linux-gnu (64-bit)
>
>         locale:
>            [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>            [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>            [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>            [7] LC_PAPER=C                 LC_NAME=C
>            [9] LC_ADDRESS=C               LC_TELEPHONE=C
>         [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
>         attached base packages:
>         [1] stats     graphics  grDevices utils     datasets  methods   base
>
>         loaded via a namespace (and not attached):
>         [1] compiler_3.0.1 tools_3.0.1
>
>
>
>         ________________________________________________
>         R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list
>         https://stat.ethz.ch/mailman/__listinfo/r-devel
>         <https://stat.ethz.ch/mailman/listinfo/r-devel>
>
>
>     --
>     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 <mailto:paul at stat.auckland.ac.nz>
>     http://www.stat.auckland.ac.__nz/~paul/
>     <http://www.stat.auckland.ac.nz/~paul/>
>
>
>
>
> --
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis

-- 
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/



More information about the R-devel mailing list