Finding the OCR box isn't robust enough to handle all Android display modes

[0xbad1d3a5]

We crash a lot when we can't find the OCR box, which happens due to the navigation bar / status bar, and apps being able to show & hide them and what not. It's especially annoying since if you rotate the device, the navigation bar does not rotate on a phone but does on a tablet. We may need to find a way to simply be able to quickly find the a exact sub-image from any image so that we aren't relying on the fragile logic of adding and subtracting status & navigation bar heights.

Candidates:

• http://stackoverflow.com/questions/29663764/determine-if-an-image-exists-within-a-larger-image-and-if-so-find-it-using-py
• http://docs.opencv.org/2.4/doc/tutorials/imgproc/histograms/template_matching/template_matching.html

[0xbad1d3a5]

Hmm...

Actually, we might not even have to be that fancy. Since what the current algorithm does anyways right now is just look for 8 consecutive horizontal pixels of some color, a simple divide & conquer algorithm going from top-down starting from the middle of the screen looking for the first 8 consecutive pixels might just be fast enough.

This could be the fallback box detection algorithm if finding by subtracting navi/status bar fails, since currently the screenshot time isn't significant anyways.

[0xbad1d3a5]

Well. Shit. Lol.

After pulling the commit @Shimizoki made and testing, it doesn't look like we can use View.getLocationOnScreen() as-is. The unfortunate thing is that the View.getLocationOnScreen() will get the actual current location of the view, as opposed to the final desired location. This causes bugs when the user rapidly moves around the OCR box.

You can see the bug here:

View.getLocationOnScreen() returned 144, but the final location of the box was 145, causing a mismatch.

[0xbad1d3a5]

I think this is finally fixed in 6a4d429497da3a31d7cc94d12156c741923d7955