Prof Brian Ripley <[EMAIL PROTECTED]> writes: > On Sat, 5 Apr 2008, Martin Morgan wrote: > >> Yes, thank you, this fixes the problem for me. >> >> As a follow-up, and again with my ignorance of where processing is >> actually occuring, it seems like the X11 window content is drawn >> directly rather than being drawn to a buffer and then blit on to the >> screen -- the original appearance of the plot is slow, compared to, >> e.g., hiding and then revealing the image once it has been plotted. > > That is not so for the default type="cairo". The problem is likely to > be that the bitblt is across the network, whereas repaint is a bitblt > from a local copy.
That makes sense, yes. > There are some comments on the X11() help page -- you may want to try > type = "nbcairo". Some changes are planned for R 2.8.0 which will > improve performance, but for now things are tuned for the most common > case of a local X11 display (although type = "nbcairo" works quite > well over my home wireless network). OK thank you for the tip. I don't want to take any more of your time, as the underlying issues seem to be on the radar. For what it's worth, my new test case is library(lattice) df=data.frame(x=rnorm(10000), y=rnorm(10000), z=0:1) doplots <- function(df) { plot(df$x, df$y) print(xyplot(y~x|z, df)) } producing (over a slow network) > X11(type="Xlib") > system.time(doplots(df), gcFirst=TRUE) user system elapsed 0.248 0.008 1.626 > X11(type="cairo") > system.time(doplots(df), gcFirst=TRUE) user system elapsed 1.928 0.140 13.574 > X11(type="nbcairo") > system.time(doplots(df), gcFirst=TRUE) user system elapsed 1.277 0.100 24.964 Probably no news here. X11(type="Xlib") gives me ok performance. With X11(type="cairo") the axes appear 'slowly' and the points quickly (maybe axis components are blitted, and then the points, instead of everything in one go?). With X11(type='nbcairo') the axes are drawn quickly and the points slowly (axes and each point drawn sequentially, I guess) and the repaint is slow (because of non-buffering, I guess). Using lattice graphics with 'cairo' can be quite painful. Thank you again. Martin >> R version 2.8.0 Under development (unstable) (2008-04-05 r45102) >> >> Thank you again for tracking down the original issue. >> >> Martin >> >> Prof Brian Ripley <[EMAIL PROTECTED]> writes: >> >>> I think I have found this -- if so, it was an X11 timing issue and we >>> needed to re-read the X11 window size at a later time. Please try >>> r45102 or later. >>> >>> On Fri, 4 Apr 2008, Prof Brian Ripley wrote: >>> >>>> On Thu, 3 Apr 2008, Martin Morgan wrote: >>>> >>>>> I apologize if this is too obscure to reproduce, or some idiosyncratic >>>>> aspects of my system. If I create a plot, e.g., >>>>>> plot(1:10) >>>>> I get a graphics device as expected. I then click on the 'zoom' box >>>>> on >>>>> my X11 window, so the window expands to occupy the entire screen. The >>>>> plot is redrawn at the scale of the large window, but is clipped to the >>>>> 'unzoomed' size. I only see the top left portion of the plot, >>>>> occupying the space of the original image. >>>>> Here are the R essentials; I'm using X11 on a recent SuSE, >>>>> connecting >>>>> via a moderately out-of-date cygwin from Windows. I'm happy to provide >>>>> more detail if pointed in the right direction (and will trouble shoot >>>>> myself if this is not a general problem). >>>> >>>> We've seen it, but not all systems do it. At present it looks like >>>> a cairo bug, but more work is needed on it. If we haven't found a >>>> workaround by release time, it will be documented on the help page. >>>> >>>>>> sessionInfo() >>>>> R version 2.8.0 Under development (unstable) (2008-04-03 r45066) >>>>> x86_64-unknown-linux-gnu >>>>> locale: >>>>> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C >>>>> attached base packages: >>>>> [1] stats graphics grDevices utils datasets methods base >>>>>> capabilities() >>>>> jpeg png tcltk X11 aqua http/ftp sockets libxml >>>>> TRUE TRUE TRUE TRUE FALSE TRUE TRUE TRUE >>>>> fifo cledit iconv NLS profmem cairo >>>>> TRUE TRUE TRUE TRUE TRUE TRUE >>>>> Martin >>>>> -- >>>>> Martin Morgan >>>>> Computational Biology / Fred Hutchinson Cancer Research Center >>>>> 1100 Fairview Ave. N. >>>>> PO Box 19024 Seattle, WA 98109 >>>>> Location: Arnold Building M2 B169 >>>>> Phone: (206) 667-2793 >>>>> ______________________________________________ >>>>> R-devel@r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>>> >>>> >>>> -- >>>> Brian D. Ripley, [EMAIL PROTECTED] >>>> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ >>>> University of Oxford, Tel: +44 1865 272861 (self) >>>> 1 South Parks Road, +44 1865 272866 (PA) >>>> Oxford OX1 3TG, UK Fax: +44 1865 272595 >>>> >>> >>> -- >>> Brian D. Ripley, [EMAIL PROTECTED] >>> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ >>> University of Oxford, Tel: +44 1865 272861 (self) >>> 1 South Parks Road, +44 1865 272866 (PA) >>> Oxford OX1 3TG, UK Fax: +44 1865 272595 >> >> -- >> Martin Morgan >> Computational Biology / Fred Hutchinson Cancer Research Center >> 1100 Fairview Ave. N. >> PO Box 19024 Seattle, WA 98109 >> >> Location: Arnold Building M2 B169 >> Phone: (206) 667-2793 >> > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UK Fax: +44 1865 272595 -- Martin Morgan Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M2 B169 Phone: (206) 667-2793 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel