Does Processing3 (v3.3.6) in Android mode restrict frameRate() from going higher than ~60fps?

Xaracen

While testing my S7 Edge capabilities, I ran the following sketch:

void setup() { frameRate(10000); } void draw() { println(frameRate); }

It never rises above around 63-65fps, and the CPU usage sits around 10%, and no other apps are running in the background. I am aware that this sketch can produce far higher fps in other devices. Is this limit configurable somewhere?

kfrajer

Are you trying to draw faster than 60fps? Or you want to do calculations/operations at a different rate? An alternative is to use a Thread but remember to keep your drawing operations in the main thread.

Kf

Xaracen

I am drawing a graph of pulsesensor readings I am receiving over Bluetooth at one per 4ms. I can plot multiple readings in one frame, but the plotting isn't always smooth. As the graph advances it cycles over several seconds from moving in jerks to moving smoothly. I can control the rate I send the readings, but not the rate at which I get them from OnBluetoothDataEvent, and I am not losing any data.

The jerks are when OnBlue gives me multiple readings, and they get plotted rapidly, but when I only get one reading at a time, the plotting slows down but is smooth.

I was hoping a higher fps would let things run more smoothly, but there may be a way to delay when Draw plots individual readings to match the reception rate. I'm thinking I'll give that a go.

Xn

kfrajer

For smoothness and if limited by the actual drawing process, you could manage by creating an algorithm that receives and accumulates, say the last 100 timed readings (reading-time data pairs) and then when each cycle of draw is executed, you can average/extrapolite/interpolate based on the last n number of "recent" readings. You can apply this algorithm in case your data doesn't arrive fast enough, if you get more data that you can plot, or if your device has dead-times.

Another option in the case that you are receiving more data is to pick what you want to display in order to make it look smooth. I am referring to selectively discarding data.

I do not think you can refresh the drawing faster than 60fps as it depends on your hardware refreshing rate which you should be able to find in their spec sheet.

I hope this helps,

Kf

Xaracen

Thanks for that, Kf, actually just tried out having Draw wait until it had four values to plot before plotting them, on the assumption that a 60fps frameRate implies a gap of about 16ms between frames, during which I should actually have received four readings at 4ms intervals. It worked, but didn't improve matters,it looked a little worse.

I am actually plotting about 250 readings per second, and earlier tests showed I wasn't losing any of my readings (once I correctly applied synchronized, etc). Those tests also showed that Draw, OnBluetoothDataEvent and SigPlot (which does the actual plotting) only took 0-2ms each at full tilt, and mostly sat at around 1ms.

So I am not having any trouble having enough time to process stuff, it is just getting it to do so consistently smoothly. To be honest it isn't that bad, I'm probably being a wee bit picky.

But I will give your suggestion above some thought. 4ms works quite well, and I had been running at 6, 8 and 12ms intervals between sending the readings before I sorted out my occasional data loss. But more readings means a more accurate representation of the pulse waveform. I had been getting visible glitches in the graph, and was pretty certain it was due to data loss screwing up the parsing of the received data strings.

Many Thanks Xn

Xaracen

OK, been busy but things are working quite well. I am sending a 6-byte data frame every 2ms over Bluetooth, and plotting them in a graph. That all works fine, but the jitter seems to be down to Draw() not being called on exact time cycles, due to other processes running in the device.

Draw() is still only running at around 60fps, but I am now plotting 500 readings per second, so around 8 to 9 readings per frame. I am pretty happy with this and the jitter is acceptable. It does seem to settle down after a few seconds. I don't really want nor need to interpolate data when I can still plot real data. Even when I was sending my 6-byte packet every 8 or 12 or 16ms, the jitter was present, as it was down to Draw() having more or less time than the previous frame to do stuff, and it was doing pretty much the same stuff every frame. Occasionally, say about 3 times per second there would be other packets types to process, but the sketch can run for hours without dropping any data at all.

So, again, many thanks for your advice, I am now pretty comfortable with the way the sketch is behaving.

kfrajer

Great to hear @Xaracen. All the best!

Kf