High speed screen updates for oscilloscope

[Jondroid]

Dear all,

First a big thank you to Erel. I really love B4A, thanks for the good work! :sign0098:

Now, I'm trying to build an oscilloscope (similar to the IOIOscope elsewhere in this forum) but I want to have the best performance for screen updates. In order to test this I wrote a simple application which just alternates between a line and a sine. Also, I measure the time needed for those updates.
On my phone (800MHz, single core) I get about 120-130 ms for those two updates. This appears on the screen obviously not smooth but is flickering.

The question now is, if my approach in the attached file is valid or if there is another method to make high speed drawing possible.

The second question is: video files will obviously play on all devices with the same speed and one will have some 20-30 screen updates per second. Is there a way to draw my lines in a video buffer and then play this video buffer?

Many thanks in advance,
Jon

 

[Jondroid]

Gigatron, no need to upload the zip, I just forgot to add the panel1 in the designer. Now it runs on the device but I haven't had a good look at your code. Will report back in a while.

 

[Jondroid]

Gigatron, thanks for the code. Your version does indeed look very nice and no flickering and the update rate is smooth.

Now, I've looked at your code a bit but I realised that I may have not expressed my problem very clearly. I'm sorry for that and so I will try to clarify it a bit more here. In your version you clear the display, draw the sine and then the green line. Finally you invalidate the display. However, I wanted to see two different images plotted subsequent to eachother as only in that case you will notice the effect of a low frame rate. Your composed image plots on my device in about 70ms, which means a frame rate of about 14 frames per second.
So while it appears smooth it is still a fairly low frame rate and you would only notice that (i believe) if you would draw the images subsequently. E.g. if not the composed drawing is displayed but only the green line and the sine in the next frame. At very high frame rates the eye wouldn't be able to determine the two subsequent images and one has the impression of a composed image.
So my aim was to find the drawing method which is the fastest. For me this is essential to see how basic4android compares to the native java code.

 

[Jondroid]

Hi Klaus,
thank you for your version. Unfortunately, I don't find in your version that you call "DoEvents" after you invalidate the display. So the screen is not updated the 30 times but only the flag is set. You can proof this if you add DoEvents after Invalidate. Then immediately the time goes up from 10ms (on my device) to 70ms, which is exactly the same order of magnitude as Gigatrons version.

 

[Jondroid]

Klaus, attached is a version based on your version which demonstrates that without doevents the screen will not be updated. I've increased the number of screen drawings from 30 to 500 and have two different click events: one to draw the sine and one to clear the display again.

Be patient after you clicked the display the first time. It may take 2-5seconds before you see anything. That's because the screen is not updated until the sub routine is left. So you see the screen is not really updated and the figure of 10ms (on my device) is kind of meaningless.

When you click the display the second time the screen is cleared immediately.

Then you can repeat the 500 drawings again.

 

[klaus]

Hi Jondroid,
You are right, without the DoEvents the screen is not updated after each drawing.
The time increased to 22ms on the device and 50ms in the Emulator.

The attached testprogram shows it with a varying sin frequency.

Best regards.

 

[NeoTechni]

The only method I can think of is by switching to OpenGL.

 

[Jondroid]

Thanks Klaus,
Apparently your emulator is even better than my device Sounds funny, doesn't it. Well, I guess it may be just my device then. And as you and Gigatron demonstrated in real life it may not be noticable.
Thanks for all the help.

Still I wonder if there would be fundamentally different ways to make screen updates. I guess directly writing to the buffer of the graphics chip wouldn't be possible from java but then again, videos always play with high frame rates and that fullscreen. So somehow there must be a way to draw faster to the screen.

I understand that this might not be possible, but that was the reason why I asked. E.g. I wonder if one could somehow hijack a the video interface for our need. I mean like pointing the video player to a pipe and this pipe is filled from my activity with data. Something along those lines (I'm just thinking loud).

There is hardware acceleration in the android SDK, so the question is how to make use of it. I'm not sure that the methods with drawline, invalidate and doevents is the standard way to have hardware acceleration support.

Or as NeoTechni said by switching to OpenGL, but then can someone please point me to the right direction where to get started with OpenGL and drawing simple lines?

Cheers,
Jon

 

[sigges]

Hello,
I am working on my ecg viewer software and I want to view the ecg in realtime, but the screen update is not fast enough.
Nearly 1 year is over, after this topic was started and maybe a better solution is now possibly ? Maybe somebody of this very helpful forum can give me an direction-
Have a nice day
cheers
sigges

 

[KitCarlson]

Sigges,
I wrote a simple scroll chart recorder by starting with the klaus oscilloscope example. It might work for the ecg. I have found that timers work fairly well when used at 100mS or greater, below that they seem to have jitter, so software delay may work. Not sure how fast, for my app I did 3 charts, progress bars and numeric displays in loop. There was also BT communications, calculations involved, all was done easily in 100mS.

www.b4x.com/forum/basic4android-share-your-creations/26335-scroll-chart-example.html