speed optimization on convert(Frame):Bitmap #379
Conversation
|
Cool, are you sure this is faster though? AFAIK, Android isn't very efficient even on bulk operations. In any case, let's also cache |
|
Oops, I forgot to add the I'll fix that Monday. As for performance, I've been testing and profiling on N preview and it is dramatically faster. Calling convert during live camera preview frames drops cpu time from 60% to something like 20%. Behavior prior to N preview might be a little different, I haven't tested. |
|
Faster then, cool! BTW, a better way of doing it without |
pfn
force-pushed
the
master
branch
2 times, most recently
from
abdeb44
to
612ad1e
Compare
|
I forgot today is Friday and not Saturday. So, my changes are updated per feedback. |
eliminate individual get/put calls as much as possible
| int b = in.get(y * stride + 3 * x + 2) & 0xff; | ||
| rgba = (r << 24) | (g << 16) | (b << 8); | ||
| } | ||
| buffer.putInt(y * rowBytes + 4 * x, (rgba << 8) | 0xff); |
There was a problem hiding this comment.
There's going to be a problem here I think for the last pixel. It's not being shifted.
|
Great, thanks! A couple of places to fix as noted above, and it's good to merge. |
|
But looking at this more closely, the order doesn't seem to be right. We assume an input of BGR. To be less confusing, we should inverse the order of "r" and "b". And then to make sure it always works as expected, we should force |
|
I haven't had a chance to get back to this to improve it further. I will |
|
No problem, I figured I should add a test and move the old code there, to compare the results between new candidate code, against known good results. And while I'm at it I fixed your code to make the test pass. :) Thanks for the contribution and yes feel free to optimize further! |
eliminate individual get/put calls as much as possible