For what it's worth, one area where I've noticed a big change is when I add to
a
plot in a for loop. For example, many calls to 'lines' or 'points'. Notice:
> x <- runif(2000, -1, 1)
> y <- runif(2000, -1, 1)
> X11(type = "cairo")
> plot(0,0)
> system.time(for(i in 1:2000) points(x[i], y[i]))
user system elapsed
1.296 3.528 21.963
> X11(type = "Xlib")
> plot(0,0)
> system.time(for(i in 1:2000) points(x[i], y[i]))
user system elapsed
0.444 0.032 0.509
This is not a particularly wonderful example and I think in most situations
there are better ways to do something like this than putting 'points' in a
loop.
But I wonder how many developers assume that this type of operation will run
quickly?
-roger
Prof Brian Ripley wrote:
> Martin M x 2,
>
> Yes, no news in either of your most recent messages. That's a really ugly
> plot, though, and I do want to protest about either of these being worth
> doing fast.
>
> On my home system
>
>> F <- ecdf(rnorm(10000))
>> system.time(plot(F))
> user system elapsed
> 1.343 0.035 1.410
>> x11(type="Xlib")
>> system.time(plot(F))
> user system elapsed
> 0.022 0.002 0.083
>
> and if something is worth plotting, it is surely worth waiting 1.4s for?
> (About 1/4 the time is spent on antialiasing.)
>
> Martin Morgan's example is atypical (how often do people do scatterplots
> of 10,000 points? Or ecdfs, come to that?), but I see
>> X11(type="Xlib")
>> system.time(doplots(df)) # gcFirst=TRUE is the default
> user system elapsed
> 0.174 0.005 0.187
>> X11(type="cairo")
>> system.time(doplots(df))
> user system elapsed
> 2.315 0.035 2.388
>> X11(type="nbcairo")
>> system.time(doplots(df))
> user system elapsed
> 1.844 0.057 1.920
>
> However, I think the plots produced are pretty uniformative whereas using
> a smaller translucent filled disc as the symbol would give more
> information (and "Xlib" cannot do that).
>
> The BioC package flowViz has some quite extreme examples of arrays of
> scatterplots of ca 25,000 points, and they are acceptably fast with
> type="cairo" on my system (they certainly plot much faster than I would
> need to appreciate what they are trying to say).
>
> It is very easy to change the default default (X11.options(type="Xlib") in
> .Rprofile), and so the only question was 'what is best for most users?'.
> As we think they will have local displays and be working with hundreds
> rather than tens of thousands of points, the current default default seems
> the best compromise.
>
> Incidentally, windows() and quartz() are nowhere near as fast as Xlib on
> the same or similar hardware. On my laptop
>
>> system.time(plot(F))
> user system elapsed
> 0.14 0.43 0.72
>> system.time(doplots(df))
> user system elapsed
> 0.38 0.58 1.25
>
> and I don't usually feel that machine is slow (it was its 3rd birthday
> last week).
>
> I don't know how you live without graphics acceleration -- I've seen it on
> my systems (1600x1200 and 1680x1050) when drivers have failed to update
> and know I don't even want to text edit without it.
>
>
> On Sat, 5 Apr 2008, Martin Maechler wrote:
>
>>>>>>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>>>>>>> on Sat, 5 Apr 2008 16:27:52 +0100 (BST) writes:
>> BDR> 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.
>>
>> BDR> That is not so for the default type="cairo". The
>> BDR> problem is likely to be that the bitblt is across the
>> BDR> network, whereas repaint is a bitblt from a local copy.
>>
>> BDR> There are some comments on the X11() help page -- you
>> BDR> may want to try type = "nbcairo". Some changes are
>> BDR> planned for R 2.8.0 which will improve performance, but
>> BDR> for now things are tuned for the most common case of a
>> BDR> local X11 display (although type = "nbcairo" works
>> BDR> quite well over my home wireless network).
>>
>> Sorry to chime in; I had wanted to bring this to Brian's
>> attention a few days ago, but always got side-tracked:
>>
>> Here are results on my IBM/Lenowo X41 notebook
>> model name : Intel(R) Pentium(R) M processor 1.50GHz
>> cpu MHz : 600.000
>> bogomips : 1198.37
>> MemTotal: 1546600 kB
>>
>> with *no* graphics acceleration:
>> Everything is local but not really fast hardware
>>
>>> F <- ecdf(rnorm(10000))
>>> system.time(plot(F))
>> user system elapsed
>> 3.204 0.024 3.402
>>> x11(type="Xlib")
>>> system.time(plot(F))
>> user system elapsed
>> 0.068 0.000 0.354
>> which is somewhat dramatic,
>> and for tk*() pseudo-animations, I have definitely needed to use
>> type = "Xlib"
>>
>> 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]
>> BDR> Professor of Applied Statistics,
>> BDR> http://www.stats.ox.ac.uk/~ripley/ University of
>> BDR> Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road,
>> BDR> +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865
>> BDR> 272595
>>
>> BDR> ______________________________________________
>> BDR> R-devel@r-project.org mailing list
>> BDR> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
--
Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
