[Rd] X11 image problem in R-2.8.0 Under development / R-2.7
Martin Morgan
mtmorgan at fhcrc.org
Sun Apr 6 03:39:58 CEST 2008
Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
> 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.
The data motivating the original report was from quality assessment of
DNA resequencing technologies with 'intensity' measures from 8 'lanes'
each with 300 'tiles' and 36 'cycles' per tile. Intensity decreases
slightly with cycle, but failed tiles show more dramatic declines in
intensity.
xyplot(intensity~tile|lane, df)
shows successful tiles in a fuzz at a particular band of intensities,
and the number, distribution over lanes, and spatial location (implied
by tile index) of failed tiles appear as vertical streaks. Several
iterations of the plot (log intensities, lattice layout, point
representation [incl. transparency], etc) helped to clarify criteria
for identifying failures. Speed can be very valuable during this
exploratory phase, perhaps especially for those of us who are
handicapped by sometimes doing things that are not after all worth
doing. Attempting to 'zoom' as an easy way to get a closer look at
individual lanes lead to the original report.
This is the QA summary data; the underlying data consist of up to 10
million 'reads' per lane.
Thank you for your efforts. I was hoping for a bug fix (X11 repaint),
but also gained understanding of X11's type argument, consequences of
display type for different aspects of performance, and use of alpha
(vectorized, so I can, e.g., make failed tiles have alpha=1;
previously I had found that setting a scalar alpha<1 did indeed help
with point overlap, but the interesting points (failures) were
isolated and therefore faint).
Martin Morgan
> 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
>>
>
> --
> 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
More information about the R-devel
mailing list