Android Question Better Draw Performance

Scantech · Mar 29, 2019

I have 2 questions.

Which has a better performance on drawing? B4XRect or BitmapCreator DrawRect. Or are they the same?

I am really interested in faster drawing performance especially in Gradient area. My canvas draws 3 rect (using bitmapcreator) with gradient fill. 60 of them takes about 4 seconds to complete. Depending on device give or take second or two. The question for this is there anything faster than bitmapcreator in gradient area?

Thank you

MarkusR · Apr 2, 2019

Scantech said:
How is it the apps in Google Play are able to add so many gauges

screenshot or app link?

emexes · Apr 2, 2019

JPEG choked on them too, so I halved the resolution and with a bit of luck...

tadaaa!

emexes · Apr 2, 2019

This guy is at the opposite end of the get-the-job-done-vs-make-it-look-good spectrum to me:

Initially I thought he was using some add-in package, but, no, he's actually created gauges from scratch using just Excel.

Mind you, it took him two videos to get the job finished, and I didn't actually see the gauge needle move, but still... wow!

Erel · Apr 2, 2019

emexes said:
Have you tried just using Canvas to do draw the gauges, rather than the cross-platform (and probably not hardware accelerated) way?

That's an incorrect assumption. B4XCanvas and Canvas behave exactly the same as they are based on the same APIs.

BTW, another implementation of a gauge: https://www.b4x.com/android/forum/threads/b4x-xui-gauge-view.87435/#content

emexes · Apr 2, 2019

Erel said:
That's an incorrect assumption. B4XCanvas and Canvas behave exactly the same as they are based on the same APIs.

Well, I'm very glad I included the "probably" bit, then ;-) I did look at some B4X code, and all of the pixel-moving stuff that I recognised was done via the CPU, but I have no doubt that I could have missed the occasional call to the underlying OS/hardware. I'll fix up that comment above.

Scantech · Apr 2, 2019

MarkusR said:
screenshot or app link?

https://play.google.com/store/apps/details?id=OCTech.Mobile...OBDLink&hl=en

MarkusR · Apr 2, 2019

Scantech said:
https://play.google.com/store/apps/details?id=OCTech.Mobile...OBDLink&hl=en

the screenshots there show only six at one screen.

Scantech · Apr 2, 2019

MarkusR said:
the screenshots there show only six at one screen.

Download it and try it. You can add many gauges on the screen.

Scantech · Apr 2, 2019

Getting similar results out of memory using ImageView as background for Border1, Border2 and Background (complex Gradient Drawings). Added 10 to 12 (75y% x 100%x) gauges and crashed. Same as using Canvas. I can pursue further with the codes and add all the scales and labels as bitmap but i think it will result the same.

In my legacy Dashboard design, i had a background (with scales) and needle png (both small file size) eliminating most of the canvas drawing and it crashes with out of memory, too.

I guess i will keep it the original Klaus Design and rid of fancy borders and gradient. I think it will hold up and not crash. I will test it.

Update: Klaus original Design also crashes at 15 gauges.

MarkusR · Apr 2, 2019

Scantech said:
Getting similar results out of memory

upload a exported zipped test project.

Scantech · Apr 2, 2019

I modified the DrawScale Event only. Its a bit messy. i did not have time to clean it up. Related to Analog Gauges. Digital Square/Circle is not modified. Test it by clicking 'Not Used' Button to add the large gauge.

MarkusR · Apr 2, 2019

Scantech said:
I modified the DrawScale Event only. Its a bit messy. i did not have time to clean it up. Related to Analog Gauges. Digital Square/Circle is not modified. Test it by clicking 'Not Used' Button to add the large gauge.

yes, after tapping this button to add more and more gauges there is a visible slow down,
i can see if me used the test slider.

Scantech · Apr 2, 2019

I think i over exaggerated about the app from Google Play. I added 24 (100%x) Gauges and threw an exception out of memory fault. It was slowing down the app, too. The good thing about it, the app did not close. Just the Gauges layout part closed.

I believe with heap memory in manifest, my app is able to hold up to 20. I will test it.

Erel stands correct as always.

MarkusR · Apr 2, 2019

i think the way you created this Gauges is not optimal. at release mode currently it get slow after 10+ gauges.

u waste a lot of memory, but u can see only one screen.
i would try one static background and one overlay with the animations.

Scantech · Apr 2, 2019

MarkusR said:
i think the way you created this Gauges is not optimal. at release mode currently it get slow after 10+ gauges.

u waste a lot of memory, but u can see only one screen.
i would try one static background and one overlay with the animations.

The Design before this had 1 static background and overlay with animation. Similar result. Slow down will occur.

emexes · Apr 3, 2019

Scantech said:
Slow down will occur.

Mate, I got home this evening saw ^^^ and I'm like: challenge accepted!

Previously I've used a separate panel for each gauge, but both you and MarkusR referred to using "one static background and one overlay", which leaves me outvoted both quantitively and qualitively ;-) so I've given that method a go. Personally, I think the results aren't too shabby (performance-wise... presentation-wise, bear in mind that the background, dials and needles are all alpha-channeled BitMaps, so if you need fancy psuedo-reflective highlights or needles with eyeholes or whatever, that is no problem, I'm just too lazy to do it).

Starting easy, we have 16 gauges at a tad under 50 fps:

then we crank it up a bit to your required 60 gauges and we're still buzzing along nicely

and then we wonder: what happens if we go full-throttle... and we're still over 30 fps!

although, admittedly, the total workload in pixel-count terms is probably not changing much, so we wouldn't expect the time taken per frame to change much either. And you'll be needing CPU time to do other stuff as well, so that will lower the fps, but... with 16 gauges taking somewhere between 12 and 21 ms to draw and get to the display, at 10 fps that leaves you 80% CPU left to do other stuff, and at 20 fps you've still got more than 50%. Plus that's from a single-core perspective.

emexes · Apr 3, 2019

https://www.dropbox.com/s/g7xst1dhkytqy20/VID_20190403_204020.mp4

MarkusR · Apr 3, 2019

@emexes
great
give it also numbers and a prerenderd shapes as background

emexes · Apr 3, 2019

MarkusR said:
@emexes
give it also numbers and a prerenderd shapes as background

You know that costs extra, right? ;-)

Or are you saying that there is some trap awaiting in displaying numbers? Like, the needle rotation is done in hardware by the GPU, but text display is slow?

Hmm.

I really don't want to, but...

Erel · Apr 3, 2019

My implementation:

It is based on BitmapCreator and it is cross platform.

I aim to draw at 30 FPS as the visual difference will be insignificant in this case.
The seekbar at the bottom does nothing. It is only used to show that the UI is responsive.

Android Question Better Draw Performance

Well-Known Member

Well-Known Member

Expert

Expert

B4X founder

Expert

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Attachments

Well-Known Member

Well-Known Member

Attachments

Well-Known Member

Well-Known Member

Expert

Expert

Well-Known Member

Expert

B4X founder

Attachments

Similar Threads

Privacy & Transparency

Privacy & Transparency