R devel - Oct 2013 - appropriate work-around for problems with a specific plot device (Rstudio)?

Dear r-devel-opers,

I'm working on a package that does some plot-intensive work using the 
animation library.  It turns out that this performs very badly in the 
RStudio plot device, which is the preferred IDE for our team.  Our 
kludgy solution is to detect if the Rstudio device is running, and if 
so, open another plot device to do the rendering and close it when done:

externalDevice<-FALSE
   if (!is.function(options()$device)){
     if (names(dev.cur())=="RStudioGD"){
       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
     }
   }

[render a whole bunch of plot frames]

# turn off external device if using one
   if (externalDevice){
     dev.off()
   }

Although this works well for us in practice, when testing against R 
devel, we get the following NOTE:


* checking R code for possible problems ... NOTE
Found an obsolete/platform-specific call in the following function:
   ?render.animation?
Found the platform-specific devices:
   ?quartz? ?windows? ?x11?
dev.new() is the preferred way to open a new device, in the unlikely
event one is needed.


Is there a better way to resolve this situation?  We can't use dev.new() 
to open the plot device, because RStudio has set the value of 
getOption("device") to "RStudioGD".  Can anyone recommend an
alternative
method of generating a platform-appropriate device to open that won't 
generate R CMD check issues?

Thanks for your help,
  best,
  -skye

Le jeudi 24 octobre 2013 ? 17:13 -0700, Skye Bender-deMoll a ?crit
:
> Dear r-devel-opers,
> 
> I'm working on a package that does some plot-intensive work using the 
> animation library.  It turns out that this performs very badly in the 
> RStudio plot device, which is the preferred IDE for our team.  Our 
> kludgy solution is to detect if the Rstudio device is running, and if 
> so, open another plot device to do the rendering and close it when done:
> 
> externalDevice<-FALSE
>    if (!is.function(options()$device)){
>      if (names(dev.cur())=="RStudioGD"){
>        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
>      }
>    }
> 
> [render a whole bunch of plot frames]
> 
> # turn off external device if using one
>    if (externalDevice){
>      dev.off()
>    }
> 
> Although this works well for us in practice, when testing against R 
> devel, we get the following NOTE:
> 
> 
> * checking R code for possible problems ... NOTE
> Found an obsolete/platform-specific call in the following function:
>    ?render.animation?
> Found the platform-specific devices:
>    ?quartz? ?windows? ?x11?
> dev.new() is the preferred way to open a new device, in the unlikely
> event one is needed.
> 
> 
> Is there a better way to resolve this situation?  We can't use
dev.new()
> to open the plot device, because RStudio has set the value of 
> getOption("device") to "RStudioGD".  Can anyone
recommend an alternative
> method of generating a platform-appropriate device to open that won't 
> generate R CMD check issues?
How about temporarily changing the value of the "device" option to
what
you need?

I think you should also get in touch with RStudio developers to see
whether something can be done about the poor performance.


My two cents