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