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
