On Dec 6, 2009, at 8:24 AM, Romain Francois wrote: > On 12/06/2009 01:20 AM, Simon Urbanek wrote: >> On Dec 5, 2009, at 4:11 PM, Romain Francois wrote: >> >>> I agree too, I was just trying to put on the balance the amount of work >>> that would require graphics supporting connections. >>> >>> Who's willing to do it ? >>> >> >> The issue is not the will nor complexity on the GD side, but connections are >> not exposed outside of R (or at the C level), so there is currently no way >> to do it (AFAIR). Jeff Horner has proposed a patch long ago and Cairo works >> with connections if you patch R, but connections are to date still not part >> of the API. So I suspect the real issue is to create a connection API so >> packages (and devices) can use it. >> >> Cheers, >> Simon > > As much as I'd love a C API for connections, streaming graphics out to > connections don't necessarily have to depend on a C api. The trick we use in > the RProtoBuf package to stream out to a binary connection is to call the R > function writeBin several times. Something like: > > /* next element is some raw vector we want to stream out */ > SEXP nextElement = PROTECT( getNextElement() ) ; > > /* con is the INTSXP connection number */ > /* create the call : writeBin( nextElement, con ) */ > SEXP call = PROTECT( lang3( "writeBin", nextElement, con ) ); > SEXP res = PROTECT( eval( call, R_GlobalEnv) ) ; > > /* grab the number of bytes actually sent out */ > int n = INTEGER(res)[0] ; > > UNPROTECT(3) ; /* res, call, nextElement */ > > We do the same with "readBin" to read from a binary connection chunk by chunk. >
Well, that's a hack like any other and error handling will be a pain. Of course you can always use the evaluator, but I would not want to write or maintain a hack like that :) Cheers, Simon > > > >>> On 12/05/2009 07:06 PM, Tobias Verbeke wrote: >>>> >>>> Hi, >>>> >>>> Gabor Grothendieck wrote: >>>> >>>>> Its not just the time. Its also the nuisance of having to manage files >>>>> that >>>>> I never needed in the first place. >>>> >>>> I agree with Gabor that it is more than a 'nice to have'. >>>> >>>> There are situations (when integrating R with other >>>> applications) you don't want to touch a disk and >>>> manage files afterwards (e.g. when one wants to pass >>>> a byte string). >>>> >>>> A recent question on the topic can be found here: >>>> >>>> http://tolstoy.newcastle.edu.au/R/e8/help/09/11/5902.html >>>> >>>> Best, >>>> Tobias >>>> >>>>> On Fri, Dec 4, 2009 at 11:01 AM, Romain Francois >>>>> <romain.franc...@dbmail.com >>>>>> wrote: >>>>> >>>>>> On 12/04/2009 03:19 PM, Gabor Grothendieck wrote: >>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> I am looking for the data to be just as if I had read in the png >>>>>>> file (or >>>>>>> wmf file or whatever). >>>>>>> >>>>>> Hi, >>>>>> >>>>>> You are after the binary payload of the rendered graph as a png file. So >>>>>> you are going to have to go through a png file. >>>>>> >>>>>> It would be nice to be able to render to a binary connection, like a >>>>>> rawConnection, but it seems like an expensive "nice to have" >>>>>> >>>>>> >>>>>> grid.cap seems to give a bitmap and then would >>>>>>> require some sort of processing to get the png or wmf, etc. form. Also >>>>>>> note >>>>>>> that I need it for classic graphics and not just grid graphics. >>>>>>> >>>>>> grid.cap does not seem to care, baptiste code uses traditional graphics >>>>>> >>>>>> >>>>>> What I have right now works just as I want it _except_ I have to >>>>>> create a >>>>>>> file and then read it back in which seems a waste. >>>>>>> >>>>>> Can you measure the time it takes to do dev.off() and readBin ? >>>>>> >>>>>> >>>>>> On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie< >>>>>>> baptiste.aug...@googlemail.com> wrote: >>>>>>> >>>>>>> Hi, >>>>>>>> You can use grid.cap, >>>>>>>> >>>>>>>> x11() >>>>>>>> plot(1:10) >>>>>>>> g = grid.cap() >>>>>>>> dev.off() >>>>>>>> str(g) >>>>>>>> # chr [1:672, 1:671] "white" "white" "white" "white" "white" ... >>>>>>>> >>>>>>>> but as far as I understand in ?grid.cap and the underlying code there >>>>>>>> is no "capGrob" equivalent that wouldn't require opening a new device >>>>>>>> before capturing the output. >>>>>>>> >>>>>>>> I hope I'm mistaken. >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> baptiste >>>>>>>> >>>>>>>> 2009/12/4 Gabor Grothendieck<ggrothendi...@gmail.com>: >>>>>>>> >>>>>>>>> Currently I have an application that saves the current graphics image >>>>>>>>> >>>>>>>> (that >>>>>>>> >>>>>>>>> was created with classic graphics or grid graphics) to a file and >>>>>>>>> then >>>>>>>>> >>>>>>>> reads >>>>>>>> >>>>>>>>> the file back in using readBin: >>>>>>>>> >>>>>>>>> png("my.png") >>>>>>>>> plot(1:10) >>>>>>>>> dev.off() >>>>>>>>> raw.img<- readBin("my.png", "raw", size = 1, n = 100000000) >>>>>>>>> >>>>>>>>> (I am doing this on Windows but would like to be able to do it on any >>>>>>>>> platform.) >>>>>>>>> >>>>>>>>> Does the new raster functionality give me any way to get the object >>>>>>>>> >>>>>>>> raw.img >>>>>>>> >>>>>>>>> without creating the intermediate file, my.png? If so what is the >>>>>>>>> corresponding code? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Nov 30, 2009 at 8:17 PM, Paul >>>>>>>>> Murrell<p.murr...@auckland.ac.nz >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> 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/<http://www.stat.auckland.ac.nz/%7Epaul/> >>>>>>>>>> >>>>>>>>>> <http://www.stat.auckland.ac.nz/%7Epaul/> >>>>>>>>>> >>>>>>>>> <http://www.stat.auckland.ac.nz/%7Epaul/> >>>>>> -- > > -- > Romain Francois > Professional R Enthusiast > +33(0) 6 28 91 30 30 > http://romainfrancois.blog.free.fr > |- http://tr.im/Gq7i : ohloh > |- http://tr.im/FtUu : new package : highlight > `- http://tr.im/EAD5 : LondonR slides > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel