speed compatibility to RStudio's plot device

[skyebend]

I've run into issues where rendering animations slows to a crawl when using animation library in RStudio. It seems that this may be caused by the fact that that the RStudio plot device is caching all of the plots (as is the animation lib, to replay with ani.replay(). For the past year or so, the ndtv package has used this code as a work around:

  if (!is.function(options()$device)){
    if (names(dev.cur())=="RStudioGD" & doRStudioHack){
      message("RStudio's graphics device is not well supported by ndtv, attempting to open another type of plot window")
      # try to open a new platform-appropriate plot window
      if (.Platform$OS.type=='windows'){
        windows()
      } else if(length(grep(R.version$platform,pattern='apple'))>0)  # is it mac?
      {
        quartz()
      } else {  # must be unix
        x11()
      }
      externalDevice<-TRUE
    }
  }

This works reasonably well, but raises the ire of R CMD check --as-cran, since it requires doing platform-specific device opening, rather than relaying on plot.new() to make the appropriate choice. I can't call plot.new(), since RStudio has overridden it to generate an RStudio device. Does anyone know of a way to find out what plot device would be called without RStudio? Or even better, is there some way to instruct the RStudio device to temporarily disable caching?

[yihui]

I'm aware of this issue and I've been using something similar to your workaround. I have no idea how to fix this issue on RStudio's side, but I guess the issue with R CMD check should not be a problem if you use grDevices::, e.g. I have quartz() in knitr: https://github.com/yihui/knitr/blob/master/R/plot.R#L40 but R CMD check does not really warn against it. Worst case is you fool R CMD check by do.call('quartz') (R CMD check does not always make sense, so I think it is fine to fool it and I do it myself sometimes).

[skyebend]

thanks! I'll try that. Perhaps a longer-term solution would be to ask @jjallaire to add a function like newPlatformDevice() to the rstudioapi, that would call whatever plot.new() would normally call. Then we could just detect if RStudio is running, and then call it via the API.

[yihui]

Personally I also hope there is an option to use R's default graphics device as well (which of course won't work for RStudio Server).

[skyebend]

BTW, I now see a new argument to dev.new(noRStudioGD = TRUE) added in R 3.1.1. it works on Windows, just not on unix systems (creates pdf instead of interactive x11 device) which I think is a bug. Posting to R-devel ...

[yihui]

Thanks! I just saw your post to R-devel.