Re: [Rd] grid.cap() requires more time?
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
[Rd] grid.cap() requires more time?
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 tifftcltk X11 aqua http/ftp sockets libxml fifo clediticonv NLS profmemcairo TRUE TRUE TRUE TRUEFALSE 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
Re: [Rd] grid.cap() requires more time?
I just figured out what the strange noise consisted of in the captured output of my previous example, and this is another source of curiosity for me, quartz(width=0.1, height=0.1) gg - grid.cap() dev.new() grid.raster(gg) Should grid.cap() really capture the resizing handle of the quartz() window? Best regards, baptiste On 17 April 2010 12:34, baptiste auguie baptiste.aug...@googlemail.com 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
Re: [Rd] grid.cap() requires more time?
Baptiste, first, there is a mailing list specifically for Mac questions - R-SIG-Mac. 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. b) it will contain the resize mark because it is a screen shot so the mark is actually part of it (this is intentional). 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. 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). 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 tifftcltk X11 aqua http/ftp sockets libxml fifo clediticonv NLS profmemcairo TRUE TRUE TRUE TRUEFALSE 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
Re: [Rd] grid.cap() requires more time?
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
Re: [Rd] grid.cap() requires more time?
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 tifftcltk X11 aqua http/ftp sockets libxml fifo clediticonv NLS profmemcairo TRUE TRUE TRUE TRUEFALSE 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
