Android Question Better Draw Performance

[Scantech]

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]

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...

more as occupational therapy but the number output take also time.

your trophy is a "master of gauges" award if it looks like the mentioned obd app.

 

[emexes]

I'm not really feeling the urge to do this, because the gauge dial background and needle are full-color and alpha-enabled bitmaps, so somebody more artistic than me can craft their masterpiece down to the last pixel. I started pulling the needle and dial images out of the Excel bloke's example, but... I don't have the appropriate tools ready to go, was just using Windows Paint, and it was going to be rough.

So instead I've programatically added a three-dee-ish border, and made the dials 50% transparent so that there is some detail showing through from the background image. My first attempt with the numbers is below - I thought I'd have trouble finding an appropriate size, stuff up the positioning, all sorts of disasters, but... it came out pretty well given that this pilot was flying blind.

 

[emexes]

Would you like the needle to pass behind or in front of the number?

 

[emexes]

Adding numbers increases the paint time by about 50%. They are put on the needle layer, and thus they are "see through" . If you wanted to have a background to the number, like maybe an odometer-style thing, then you'd add that to the static background.

Speaking of which, thanks for prompting me to try this all-on-one-layer thing, I'm quite pleased with the speed improvement compared to having each gauge on its own layer, even though I haven't had the performance challenges with my apps that Scantech's having with his way more complex one.

As much as I enjoy programming, I'm going to call this issue: job done.

 

[emexes]

https://www.dropbox.com/s/spvnsh0m53wloe1/VID_20190403_223646.mp4

(alternates with/without numbers every 5 seconds)

 

[MarkusR]

i started also a gauge custom view just for fun i will try later at phone.

cheap paint app https://www.pl32.com/

 

[emexes]

Just for fun, you reckon?!?! I don't know about you, but I wince everytime I see those fancy bezels taking up all that room... I will admit that they do look good, though.

When I saw the opening screen of the Excel Guy's three gauges, my first thought was: that's a f'n lot of space just to show three numbers ;-)

Now I have to crawl back to that video to find out how them bezels are made :-/

 

[emexes]

My implementation

1/ When did you sneak that post in?!?!

2/ Most times when I read your code, it reminds me of the quote: Any sufficiently advanced technology is indistinguishable from magic.

My only hope to salvage some confidence here... I think your needles are drawn programmatically rather than using a rotated image bitmap, which I think gives greater latitude to simulating real-world gauges.

 

[klaus]

I tested with 200 gauges with the original xGauges class.
It runs OK on my Samsung Galaxy S8 and on my Samsung Tab S2.
The gauges are put on a Scrollview.
When the number of gauges is above about 220, the value update becomes slower.
The needles are panels which are rotated.

 

[emexes]

The needles are panels which are rotated.

What?? You can rotate panels?!?!?! Man, I wish I'd known that 24 hours ago!!!

So, after fixing the typo that hardcoded the test grid to 2 columns, I put that thing through its paces, with 40 gauges displayed (visible) on screen, at varying sizes (just in case there was any optimisation going on by reusing precomputed needles between gauges) and with transparent backgrounds and gauges over the top of each other, and holy cow... it all worked. That is pretty schmicko.

If there is indeed a "Master of Gauges" award, I vote it goes to Klaus.

 

[emexes]

That panel-rotation feature might be the clincher that shifts me over to XUI. I am guessing that it is done in hardware when compositing the frame to the display buffer, which is even better (assuming there's a GPU on hand) because it doesn't come out of the CPU cycle budget. I'm intrigued what happens if you have rotated views within rotated views, but... everything else looks good, so no doubt that's been implemented right too.

 

[emexes]

To add an optimistic flavour to apps, by making sure the needle is always pointing UP:

https://www.dropbox.com/s/qhym1b0i3hjxdg1/RotationSquared.mp4

This'll be great for us in the Southern Hemisphere, no more having to make corrections like this:

 

[klaus]

(just in case there was any optimisation going on by reusing precomputed needles between gauges)

In the xGauges class, the default needles are drawn onto the needle panel during the gauge initialisation.
You can also use other custom bitmaps.

 

[MarkusR]

test with a raytraced border