On Aug 22, 2010, at 3:32 AM, Laurent wrote: > On 21/08/10 23:31, Simon Urbanek wrote: >> >> On Aug 21, 2010, at 8:46 AM, Laurent wrote: >> >>> On 21/08/10 12:00, r-devel-requ...@r-project.org wrote: >>>> >>>> On Aug 20, 2010, at 1:59 PM, Matt Shotwell wrote: >>>> >>>>>> On Fri, 2010-08-20 at 12:58 -0400, Sharpie wrote: >>>>>>>> >>>>>>>> Donald Paul Winston wrote: >>> (...) >>>>>>>> >>>>>>>> Donald Paul Winston wrote: >>>>>>>>>> >>>>>>>>>> It appears R insists on directing plot output to a >>>>>>>>>> file. Is their a graphics device that keeps the >>>>>>>>>> output in memory so it can be returned to my java app >>>>>>>>>> as a stream of bytes? If I have to wait for it to >>>>>>>>>> write to a "unique file" and then read it back again >>>>>>>>>> then I don't think that's going to work. My web app >>>>>>>>>> needs to support hundreds of concurrent clients. >>>>>>>>>> >>>>>>>> >>>>>>>> As far as I know all R graphics output that does not go >>>>>>>> to a screen device, such as an X window, must be directed >>>>>>>> to some sort of file. I am not aware of a graphics >>>>>>>> device that provides output to something other than a >>>>>>>> screen or a file, but there very well may be such a >>>>>>>> device in existence. >>> >>> For experimentation purpose, the rpy2 project is finalizing a >>> system to allow Python-written graphical devices (no C-level R >>> extensions, just Python). Beside other niceties, it will allow >>> working around the lack of connection API in R for graphics. Since >>> Python makes the use of file-like objects straightforward, we plan >>> providing devices that are streams (nice for serving graphics from >>> web applications without having to worry about temp files). >>> >> >> Well, that doesn't help with the issue we raised since you still >> cannot use R connections. > > I do think it will in the use-case proposed: have R serve graphics without > having to worry about writing temp files.
Actually I have completely forgotten that I have implemented that in Cairo already -- you can fetch the current image from any image Cairo device (without even closing it) using the .image() function. So for example you could use something like: Cairo(640, 480, "/dev/null", "png") ## the file is actually not used in this case at all so you can use anything plot(...) ## get the image (as a reference) i=Cairo:::.image(dev.cur()) ## if your code can take direct pointer (RGBA), you're done. If you want to further convert it to RAW and more, then: r=Cairo:::.ptr.to.raw(i$ref,0,i$width*i$height*4) dim(r) = c(4, i$width, i$height) p=writePNG(r, raw()) ## p is now the raw PNG content - ready to be served to the client as image/png -- no files involved > Python is somewhat used in the web applications world, and what is proposed > allows serving graphics without a temp file in sight. > Somewhat is the key word ;) but nonetheless I'm not sure I understand how you plan to do that because you'd have to embed R for this which will cause you to have to initialize R which is simply too slow for any serious web processing .. If you go the other way round (like starting with Rserve) then you don't have Python as a starting point so you'd have to load Python for that in the first place which seems like an overkill. Cheers, Simon >> It's trivial to modify any of the existing >> devices (e.g. Cairo as I said) to support in-memory storage as they >> already support that internally - certainly much easier that to mess >> with Python etc. > > I have been neck-deep in R C-level code for devices when working on that, and > ended up with the exact opposite opinion. > >> Nonetheless, yes, it is another way along the lines >> of xGD, JavaGD etc. > > Thanks for the pointer. I did not know about them. > JavaGD might well be the most helpful thing then (if Donald had in mind to do > the web handling made in Java). > > > Best, > > > Laurent > > >> Cheers, Simon >> >> >> >>> >>>>>> This was essentially the conclusion of Donald's earlier >>>>>> thread... >>>>>> >>>>>>>> The functionality you could describe could be implemented >>>>>>>> by writing a R graphics device that forwards the R >>>>>>>> plotting commands to... well anywhere you want, really. >>>>>>>> As the author of an R graphics device, I can say the >>>>>>>> trickiest part of such an undertaking will be calculating >>>>>>>> font metrics so that R can properly position text in the >>>>>>>> graphics. Everything else is very straight-forward. >>>>>> >>>>>> I believe Donald wants the_rendered_ output. That is, a >>>>>> stream of bytes that represent a png, jpeg, etc. Toward this >>>>>> end, we have already discussed using an OS-level fifo to >>>>>> avoid disk I/O, and I think this is the easiest route for >>>>>> Donald. >>>>>> >>>>>> Alternatively, Donald might look into the X11 graphics >>>>>> driver, where Cairo is used to write pngs. In particular, the >>>>>> in_do_saveplot function (src/main/modules/X11/devX11.c) calls >>>>>> cairo_surface_write_to_png, in order to save a png to file. >>>>>> Cairo also provides the cairo_surface_write_to_png_stream >>>>>> function, which might be used to send png data to a memory >>>>>> buffer (i.e. a raw vector). I don't think it would be too >>>>>> difficult to modify in_do_saveplot to accommodate this. >>>>>> >>>> That is all nice, it will require you to hack R (well, there is >>>> the Cairo device so you could make the change outside of R >>>> instead). >>>> >>>> As always, the reason is buried deep inside -- the lack of >>>> connection API. If we had that, devices would take a connection >>>> instead of the file name and all would be well since you could >>>> use in-memory connections instead of files ...;) >>> >>> May I dare asking about what happened to past offers to alleviate >>> the problem ? >>> >>> There is at least one patch (contributed 4 years ago) >>> http://rwiki.sciviews.org/doku.php?id=developers:r_connections_api >>> that remained seemingly ignored, and subsequent requests for >>> updates (or patch submission policies) remained similarly >>> unanswered. >>> >>> A recent thread showed unexpected progress, with the eventual >>> possibility of accepting a patch being worded. >>> http://www.mail-archive.com/r-devel@r-project.org/msg20276.html >>> Unfortunately the thread drifted into legalese invocations, and >>> despite the author of the patch complying to all demands regarding >>> the licensing flavour for his contribution the patch seems to have >>> joined (all ?) other submitted patches. (I don't get anything when >>> running: svn log -r {2010-04-27}:HEAD | grep -i Shotwell ). >>> >>> Are there such patches included in the Revolution R sources, or are >>> there plans to do so ? >>> >>> >>> >>> Laurent >>> >>> >>> >>> >>>> Cheers, Simon >>>> >>>> >>>> >>> >>> >> > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
