Hi, I submitted a bug report today.
On 17 April 2010 22:34, Simon Urbanek <simon.urba...@r-project.org> wrote: > 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. This would be very useful, I think. In fact, it sounds like it might be possible to convert a set of graphical commands directly into a raster representation, without creating an intermediate file nor opening an interactive device window. That would be awesome. Thanks, baptiste > > 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
