| Author |
 Topic  |
|
quinncurtis
1586 Posts |
 Posted - 22 Sep 2016 : 11:05:36
|
If you turn off the RTScrollFrame y-axis auto-scaling, and use the external auto-scaling already discussed, does everything work under all of your scenarios?
|
 |
|
|
wygonski
USA
18 Posts |
Posted - 22 Sep 2016 : 18:33:02
|
No. If I update the graph every 200ms, it seems that whether I autoscale "manually" or with RT_AUTOSCALE_Y_MINMAX, I still have issues. Slowing down the update to 600ms fixes the problem. Reducing the interval of displayed data from 3s to 1s fixes the problem. Also, if the Y axis range for the "random" number plot is scaled large with respect to the data (e.g. range of 0-500 for data varying between 320-350, the problem is fixed.
Does it also seem to you that the problem is related to writing to the screen? |
|
|
|
wygonski
USA
18 Posts |
Posted - 22 Sep 2016 : 21:43:21
|
| So if I can tolerate some lag in displaying the scrolling graph, is it feasible to update the display in another thread (not the UI thread) so that the UI remains responsive? I have some buttons in another fragment that turn the data stream on and off, change the data that is streamed, etc. |
|
|
|
quinncurtis
1586 Posts |
Posted - 23 Sep 2016 : 09:20:22
|
No, you can't update the display from a non-ui thread. You can acquire the data for the display from a non-ui thread. That's standard Android programming.
I want to go back to your original assertion that the slow-down only occurs when the data varies large amounts from point to point, compared to a simple smooth signal of the same number of data points. With your further experimentation, do you still think this is true? This points to some problem with the Android polyline routine where it breaks down for large point counts of highly varying data. Our software does not treat the two signal types differently. |
|
|
|
wygonski
USA
18 Posts |
Posted - 23 Sep 2016 : 11:41:14
|
I can switch between scenarios with the following code:
scrollFrame.setScrollScaleModeY( ChartConstants.RT_NO_AUTOSCALE_Y);
/*
maxH = 3600.0;
minH = 0.0;
*/
maxH = 340.0;
minH = 310.0;
/**/
scrollFrame.getChartObjScale().setScaleStartY( minH );
scrollFrame.getChartObjScale().setScaleStopY( maxH );
// what does this do? html doc is blank on this method:
scrollFrame.setScrollRescaleMargin( 0.05 );
// Allow 10 samples to accumlate before autoscaling y-axis. This prevents rapid
// changes of the y-scale for the first few samples
scrollFrame.setMinSamplesForAutoScale ( 10 );
chartVu.addChartObject(scrollFrame);
The display is updated every 200ms, and the scrolling graph is set to display 3s of data at 200 points/sec.
"working" scenario: (minH,maxH) = (0.0,3600.0)
graph lagging and UI buttons unresponsive: (minH,maxH) = (310.0,340.0)
|
|
|
|
quinncurtis
1586 Posts |
Posted - 23 Sep 2016 : 12:04:00
|
OK, in both of your scenarios, what is the actual dynamic range of the data.
Is this a clipping issue, i.e. when the data is clipped the chart slows? |
|
|
|
wygonski
USA
18 Posts |
Posted - 23 Sep 2016 : 12:09:35
|
No, the data is random but the actual range of the data is (315.0,335.0). No clipping is visible.
And not to distract the discussion, but when the data is the periodic square wave, i.e., data values alternating periodically between -1000.0 and 1000.0, and the visible data fills the plot area, the plot is in the "working" scenario. |
|
|
|
quinncurtis
1586 Posts |
Posted - 23 Sep 2016 : 15:16:36
|
We wrote a simple program (two traces, 200 Hz data update, 5 Hz display update, x-axis displays 3 seconds, y-autoaxis enabled, scroll frame reset margin at 0.05) to test your basic setup and cannot make the software act the way you describe. We were using an old Nexus 7 2012 as the test hardware. I assume you are using test hardware at least as fast as that?
If you are able to make yours work using simulated data (i.e. no dependencies we wouldn't have), send us a complete Android Studio project we can run and debug, where some sort of flag will toggle between your fast and slow mode. Send the zipped project as an attachment to support@quinn-curtis.com
|
|
|
|
wygonski
USA
18 Posts |
Posted - 23 Sep 2016 : 17:10:22
|
Firstly, I really appreciate the support and response on this issue. I've been running on a Google Nexus 7, and a Samsung Galaxy S4.
It will take some time for me to decouple my code from the bluetooth connection management and the data input stream so that my app can run standalone. The part of my app's UI that becomes unresponsive is a toggle button that sends a command over bluetooth to my hardware, and then waits for a response and displays that text message. I will write a software driver that simulates this part and data generation.
I can probably get it to you by tomorrow, knowing that you may not get to it until the start of the week.
Thanks again. |
|
|
|
quinncurtis
1586 Posts |
Posted - 27 Sep 2016 : 08:31:47
|
We determined that the issue is clearly in the Android graphics polyline drawing routine. It is slowing down to a crawl for certain types of waveforms. It is probably related to some combination of long polyline runs, thick line widths, close adjacent points, and anti-aliasing.
But, the simple solution is to NOT use a thick line width for the drawing object of the real-time plot. In your program that means changing the line width of the SimpleLinePlot to 1.
ChartAttribute attrib1 = new ChartAttribute (ChartColor.YELLOW, 1,ChartConstants.LS_SOLID);
.
.
.
SimpleLinePlot lineplot1 = new SimpleLinePlot(pTransform1, null, attrib1);
lineplot1.setFastClipMode( ChartConstants.FASTCLIP_X);
rtPlot1 = new RTSimpleSingleValuePlot(pTransform1,lineplot1, inputChannel1);
chartVu.addChartObject(rtPlot1);
We also tried a line width of 2, and that seemed to work, but not a line width of 3. Try and a width of 1 and 2 in your program to see if 2 is fast enough, otherwise revert to 1.
Let us know the results. |
|
|
|
wygonski
USA
18 Posts |
Posted - 28 Sep 2016 : 01:56:34
|
When I read your findings, it made sense because that matched every symptom I had described to you. Thanks much for taking the time to work with my app to determine the cause of the issue.
I had a change to implement your suggested change on both my simulated and "live" app. I tested it on a Samsung Galaxy S4 and on a &" tablet. In either case, the UI and scrolling graph performance is only acceptable with a line width of 1. However, the visibility of the plot deteriorates significantly with that setting. I tried a line width of 2 but the UI was still sluggish. Perhaps some other combination of background color and line color with line width of 1 would be more visible--I'll experiment.
So if I understand your response, the underlying line drawing routine is the limiting factor, and that is out of your control since you're using the Android API, is that correct? Is there a way to override that method with something faster? I'm looking for a way to have a fast plot update and have it visible, too.
|
|
|
|
quinncurtis
1586 Posts |
Posted - 28 Sep 2016 : 08:47:41
|
Yes, that is the case. We do not see anyway to plot all of the points in the exact scale that you want, with a thick line width, as the limiting factor is the Android graphics engine. If the thick line width is the critical factor, then you will probably have to reduce your effective sample rate to half, or one third, using a two or three point average. I expect that the line drawing will speed back up once the thick points of the scroll line no longer overlap, which they do in your original scenario.
|
|
|
|
wygonski
USA
18 Posts |
Posted - 28 Sep 2016 : 10:18:03
|
| Ok, thanks for the suggestion to decimate the data for display, and thanks for the great tech support. |
|
|
|
Topic |
|
|
|
Scrolling plot is slow
