[R] Speed up plotting to MSWindows graphics window
Uwe Ligges
ligges at statistik.tu-dortmund.de
Wed Apr 27 13:32:09 CEST 2011
On 27.04.2011 12:56, Duncan Murdoch wrote:
> Jonathan Gabris wrote:
>> Hello,
>>
>> I am working on a project analysing the performance of motor-vehicles
>> through messages logged over a CAN bus.
>>
>> I am using R 2.12 on Windows XP and 7
>>
>> I am currently plotting the data in R, overlaying 5 or more plots of
>> data, logged at 1kHz, (using plot.ts() and par(new = TRUE)).
>> The aim is to be able to pan, zoom in and out and get values from the
>> plotted graph using a custom Qt interface that is used as a front end
>> to R.exe (all this works).
>> The plot is drawn by R directly to the windows graphic device.
>>
>> The data is imported from a .csv file (typically around 100MB) to a
>> matrix.
>> (timestamp, message ID, byte0, byte1, ..., byte7)
>> I then separate this matrix into several by message ID (dimensions are
>> in the order of 8cols, 10^6 rows)
>>
>> The panning is done by redrawing the plots, shifted by a small amount.
>> So as to view a window of data from a second to a minute long that can
>> travel the length of the logged data.
>>
>> My problem is that, the redrawing of the plots whilst panning is too
>> slow when dealing with this much data.
>> i.e.: I can see the last graphs being drawn to the screen in the
>> half-second following the view change.
>> I need a fluid change from one view to the next.
>>
>> My question is this:
>> Are there ways to speed up the plotting on the MSWindows display?
>> By reducing plotted point densities to *sensible* values?
>> Using something other than plot.ts() - is the lattice package faster?
>> I don't need publication quality plots, they can be rougher...
>
> I don't think there are any ways to plot in the standard device that are
> significantly faster than what you are doing if you want to see the
> updates. (I think it would be substantially faster if you hid the
> graphics window during the updates, but that won't suit you.)
>
> I'd suggest plotting a subset of the data during the updates, then plot
> the full dataset when it stops moving. For example, only plot a few
> hundred points, even spaced through the time series.
... and it highly depends on the data what can be improved. Example: For
signals essential consisting of sine functions (i.e. harmonic signals),
I am using a little dirty trick in the tuneR package, but that makes the
assumption of having a high frequency sample of a harmonic signal
without too much noise.
Uwe Ligges
> Duncan Murdoch
>
>>
>> I have tried:
>> -Using matrices instead of dataframes - (works for calculations but
>> not enough for plots)
>> -increasing the max usable memory (max-mem-size) - (no change)
>> -increasing the size of the pointer protection stack (max-ppsize) -
>> (no change)
>> -deleting the unnecessary leftover matrices - (no change)
>> -I can't use lines() instead of plot() because of the very different
>> scales (rpm-10000, flags -1to3)
>>
>> I am going to do some resampling of the logged data to reduce the
>> vector sizes.
>> (removal of *less* important data and use of window.ts())
>>
>> But I am currently running out of ideas...
>> So if sombody could point out something, I would be greatfull.
>>
>> Thanks,
>>
>> Jonathan Gabris
>>
>> ______________________________________________
>> R-help at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
More information about the R-help
mailing list