Dear all, It seems to me that grid.raster is a special case of grid.rect as far as the intended visual output is concerned. The example below illustrates how both can be used to produce an image of the volcano data,
d <- volcano cols <- grey(t(d)/max(c(d))) xy <- expand.grid(x=seq(0, 1, length=ncol(d)), y=seq(0, 1, length=nrow(d))) pdf("comparison.pdf", width=10, height=10/2*ncol(d)/nrow(d)) pushViewport(viewport(layout=grid.layout(1, 2))) pushViewport(viewport(layout.pos.r=1, layout.pos.c=1)) grid.rect(xy$y, rev(xy$x), 1/(nrow(d)), 1/(ncol(d)), gp=gpar(col=NA, fill=cols)) grid.text("grid.rect") upViewport() pushViewport(viewport(layout.pos.r=1, layout.pos.c=2)) cols.mat <- matrix(cols, ncol=ncol(d), byrow=T) grid.raster(t(cols.mat)) grid.text("grid.raster") dev.off() Of course grid.raster provides a much better output in terms of file size, speed, visualisation artifacts, and interpolation. My question though: is it necessary to have a distinct grob for raster output? Couldn't "raster" be an option in grid.rect when the width and height are constant? Alternatively, it might be useful to provide a function that converts a rectGrob into a rasterGrob, rect2raster <- function(g){ with(g, rasterGrob(matrix(gp$fill, ncol=length(unique(x))), mean(x),mean(y))) } This way, much of the existing code relying on grid.rect (e.g in lattice or ggplot2) could easily be adapted to work with grid.raster in favorable cases. Best regards, baptiste 2009/12/1 Paul Murrell <p.murr...@auckland.ac.nz>: > Hi > > This is for developers of extension packages that provide extra *graphics > devices* for R. > > In the *development* version of R, support has been added to the graphics > engine for sending raster images (bitmaps) to a graphics device. This > consists mainly of two new device functions: dev_Raster() and dev_Cap(). > > The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6 as a > marker of this change. > > This means that, at a minimum, all graphics devices should be updated to > provide dummy implementations of these new functions that just say the > feature is not yet implemented (see for example the PicTeX and XFig devices > in the 'grDevices' package). > > A full implementation of dev_Raster() should be able to draw a raster image > (provided as an array of 32-bit R colors) at any size, possibly (bilinear) > interpolated (otherwise nearest-neighbour), at any orientation, and with a > per-pixel alpha channel. Where these are not natively supported by a > device, the graphics engine provides some routines for scaling and rotating > raster images (see for example the X11 device). The dev_Cap() function > should return a representation of a raster image captured from the current > device. This will only make sense for some devices (see for example the > Cairo device in the 'grDevices' package). > > A little more information and a couple of small examples are provided at > http://developer.r-project.org/Raster/raster-RFC.html > > Paul > -- > Dr Paul Murrell > Department of Statistics > The University of Auckland > Private Bag 92019 > Auckland > New Zealand > 64 9 3737599 x85392 > p...@stat.auckland.ac.nz > http://www.stat.auckland.ac.nz/~paul/ > > ______________________________________________ > 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