On Apr 17, 2010, at 2:43 PM, baptiste auguie wrote: > Hi, > > On 17 April 2010 18:51, Simon Urbanek <simon.urba...@r-project.org> wrote: >> Baptiste, >> >> first, there is a mailing list specifically for Mac questions - R-SIG-Mac. >> > > I wasn't sure if it was Mac-specific (OK, quartz() is but I could not > test x11()). > >> Now to your post - grid.cap captures the screen of the device which has two >> implications here: >> >> a) Quartz is asynchronous -- i.e. is doesn't actually draw the content on >> screen until you're finished with drawing (for efficiency). Unfortunately R >> has no provision to tell the graphics device that it's done with drawing >> (you can always add another lines() etc.) so Quartz is simply guessing by >> measuring the time between draw commands. So when you run grid.cap while the >> output has not been drawn yet (i.e. immediately after the last drawing >> command) it will be empty as there is no content yet since Quartz is waiting >> for the end. > > OK, that makes sense. > >> >> b) it will contain the resize mark because it is a screen shot so the mark >> is actually part of it (this is intentional). > > This design decision surprises me. Would it be possible to have an > option not to capture this mark as well? >
I don't think so because the mark is part of the Quartz view - it is not something the device adds so it is not a "design decision". Again I can only repeat that if you want a re-play of the draw commands you should use that instead - it's a different task. >> >> If what you really want is a bitmap from the device, it's better to use >> quartz.save instead (followed by readPNG if you want the bitmap as raster) >> -- that actually re-runs the plot in a separate quartz device that is not >> on-screen so neither of the above are an issue. > > I thought the aim of grid.cap was to make it easier to capture a > bitmap copy (no need to create an external file). Is a screenshot more > useful? I didn't write grid.cap() so I don't know what the intention was, but "capturing a bitmap copy" is exactly the above (that is why it is called "capture" I suppose). What you are requesting is something different - creating a new bitmap using the same device settings and quartz.save does that. It would be trivial to add a parameter to quartz.save to return the bitmap directly instead of a file, but R did not have direct bitmap support so it was not requested so far. Cheers, Simon >> >> That said, you can file a) as a bug against Mac version of R (at >> https://bugs.r-project.org/ ) since grid.cap should actually trigger the >> flush before it does the capture. I cannot promise that the fix will make it >> to 2.11.0, though, because it may be non-trivial to trigger the asynchronous >> flush and wait for it without blocking something (I'll have to look). >> > > Will do. > > Thanks, > > baptiste > > >> Thanks, >> Simon >> >> >> On Apr 17, 2010, at 6:34 AM, baptiste auguie wrote: >> >>> Dear all, >>> >>> I am puzzled by the following behavior of the new grid.cap() function, >>> which appears to run out of time when capturing the output of a >>> graphic. It works fine if I introduce a Sys.sleep(1) before executing >>> more code, >>> >>> library(grid) >>> >>> quartz() >>> grid.circle(gp=gpar(fill="black")) >>> gg <- grid.cap() >>> dev.new() >>> grid.raster(gg) ## completely blank >>> gg[gg!="white"] ## indeed >>> >>> quartz() >>> grid.circle(gp=gpar(fill="black")) >>> Sys.sleep(1) >>> gg <- grid.cap() >>> dev.new() >>> grid.raster(gg) ## OK >>> gg[gg!="white"] >>> >>> I tried to see if the problem was limited to the quartz() device but >>> for some reason the x11() device is not working for me in this R >>> version, >>> >>> capabilities(what = NULL) >>> jpeg png tiff tcltk X11 aqua http/ftp >>> sockets libxml fifo cledit iconv NLS profmem cairo >>> TRUE TRUE TRUE TRUE FALSE TRUE TRUE >>> TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE >>> Warning message: >>> In doTryCatch(return(expr), name, parentenv, handler) : >>> unable to load shared library >>> '/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so': >>> dlopen(/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so, >>> 6): Library not loaded: /usr/X11/lib/libpng12.0.dylib >>> Referenced from: >>> /Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so >>> Reason: Incompatible library version: R_X11.so requires version >>> 42.0.0 or later, but libpng12.0.dylib provides version 36.0.0 >>> >>> sessionInfo() >>> R version 2.11.0 RC (2010-04-16 r51754) >>> i386-apple-darwin9.8.0 >>> >>> locale: >>> [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 >>> >>> attached base packages: >>> [1] grid stats graphics grDevices utils datasets >>> methods base >>> >>> loaded via a namespace (and not attached): >>> [1] tools_2.11.0 >>> >>> I would appreciate if someone could confirm this behavior. Pointers to >>> a fix for the x11() device on my machine are also welcome! >>> >>> Best regards, >>> >>> baptiste >>> >>> ______________________________________________ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> >> >> > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
