From rpeng at jhsph.edu  Mon Apr  7 15:45:55 2008
From: rpeng at jhsph.edu (Roger D. Peng)
Date: Mon, 07 Apr 2008 09:45:55 -0400
Subject: [Rd] X11 image problem in R-2.8.0 Under development / R-2.7
In-Reply-To: <alpine.LFD.1.00.0804051751030.8462@gannet.stats.ox.ac.uk>
References: <47F563C5.6090604@fhcrc.org>	<alpine.LFD.1.00.0804040621130.863@gannet.stats.ox.ac.uk>	<alpine.LFD.1.00.0804051457340.8444@auk.stats.ox.ac.uk>	<6ph1w5ke4hf.fsf@lamprey.fhcrc.org>	<alpine.LFD.1.00.0804051616280.6247@gannet.stats.ox.ac.uk>	<18423.44293.301180.983774@cmath-5.math.ethz.ch>
	<alpine.LFD.1.00.0804051751030.8462@gannet.stats.ox.ac.uk>
Message-ID: <47FA2593.2010108@jhsph.edu>

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 <ripley at stats.ox.ac.uk>
>>>>>>>     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 <ripley at stats.ox.ac.uk> 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 at r-project.org mailing list
>>    >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>    >>>>>
>>    >>>>
>>>>> --
>>>>> Brian D. Ripley, ripley at stats.ox.ac.uk 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, ripley at stats.ox.ac.uk 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,                  ripley at stats.ox.ac.uk
>>    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 at r-project.org mailing list
>>    BDR> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
> 

-- 
Roger D. Peng  |  http://www.biostat.jhsph.edu/~rpeng/



[Rd] X11 image problem in R-2.8.0 Under development / R-2.7
Roger D. Peng