Because they're always discrete values and can never be inbetween.
Also, calling `drawBitmap()` with float values can lead to slightly
distorted renderings because the image is interpolated between
pixels then.
So let's just avoid this by using integers.
It's probably better to restore the original situation than
having the button stay where it is.
Also clean up DetectorView a bit and refactor some variables.
Nobody knows the button is a handle that can be used.
So the natural thing to do is to tap on it which should do the
next best thing and that is showing a default region of interest.
Maybe the button should be positioned above the fab and have a
different color when inactive.
Treat VCALENDAR like VEVENT types as VCALENDAR is just a wrapper
around a VEVENT.
Also add a few simple tests for VCARD, VCALENDAR and VEVENT to
make sure everything works as expected.
With Gesture Navigation, a back may also move the image a bit
what will cause the view to redraw and to vibrate even if the
activity is already finishing.
At the time of writing, it's important to _not_ have the NDK available
when compiling the custom rotation kernel. This will produce a broken
build for some ARMv7 devices running Android 6 (e.g. One Plus X,
Yotaphone 2, Moto E) while it works for newer Android versions.
Add a new setting that will automatically rotate every other frame
by 90 degrees. This makes it possible to read vertical 1D barcodes
too. ZXing can read 1D barcodes horizontally only.
The setting is unset by default because it makes recognition of 1D
barcodes a tiny bit slower since half of the frames are now useless
for ZXing (because the barcode is in the wrong orientation on them).
On a fast device, this is hardly noticeable. But on a low-end device
it makes a slight difference which is why the setting is unset by
default.
Always running `RenderScript.forceCompat()` interferes with the
`forceCompat` flag that is set/unset if there is a RSRuntimeException.
Now that the app is restarting automatically for a RSRuntimeException
this special handling is no longer required anyway.
And toggle the forceCompat flag instead of setting it to true
so it works the other way round too.
Of course, this makes much more sense if there was a switch to
manually enable/disable forceCompat so a user can play with it.
On the other hand, I don't want users to bother with this.
So it's probably best to try and fix this behind the curtain.
