J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Description • 9 years ago

When testing on the Flame, the WiFi auth image preview is very grainy any hard to read.  This could also imply that the images sent to QR decoder are poor quality, leading to long scanning times since the images are bad.

The Camera app in contrast has a great preview.  I hope to find a way to resolve this while still using gUM instead of mozCamera.

Interestingly, the auth scanner's preview looks good on b2g desktop / simulator, but I know that's quite a different code path.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 1 • 9 years ago

The flame currently gives a super low resolution with gUM (144 x 176), so that is probably the reason.  Bug 1146637 filed about this.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 2 • 9 years ago

Jan, these changes will: 

* grab a better picture to improve chances of scanning success
* switch to data URLs to scan 2x faster

However, QR recognition is still very long with just this.  See bug 1152836 for work to improve the recognition time.

	Jan Keromnes [:janx]
	Comment 3 • 9 years ago

Great! I'll give it a try.

	Jan Keromnes [:janx]
	Comment 4 • 9 years ago

I really like this pull request, but I was out of luck for my first try:
- Without patch, 1st try took 7 seconds.
- With the patch, 1st try took about a minute.
- 2nd try took 1.5 minutes, I gave up, but then it connected.
- 3rd try took 1.5 minutes again, then WebIDE timed out and the Flame was completely frozen (took an additional minute to become responsive again).

I'll try again with your patches from bug 1152836.

	Jan Keromnes [:janx]
	Comment 5 • 9 years ago

Comment on attachment 8590531 [details] [review]
Pull Request

Scan time could probably be improved even further (some QR scanners are almost instant) but it definitely gets a lot better with all patches applied!

Thanks for addressing this.

	Jan Keromnes [:janx]
	Comment 6 • 9 years ago

P.S. Maybe wait for the optimization patches to land before merging this?

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 7 • 9 years ago

(In reply to Jan Keromnes [:janx] from comment #4)
> I really like this pull request, but I was out of luck for my first try:
> - Without patch, 1st try took 7 seconds.
> - With the patch, 1st try took about a minute.
> - 2nd try took 1.5 minutes, I gave up, but then it connected.
> - 3rd try took 1.5 minutes again, then WebIDE timed out and the Flame was
> completely frozen (took an additional minute to become responsive again).
> 
> I'll try again with your patches from bug 1152836.

Yes, I guess an overall slowdown makes sense without bug 1152836 applied, since we're pushing more image data to decoder, and it takes quite a long time to process the data.

(In reply to Jan Keromnes [:janx] from comment #5)
> Comment on attachment 8590531 [details] [review]
> Pull Request
> 
> Scan time could probably be improved even further (some QR scanners are
> almost instant) but it definitely gets a lot better with all patches applied!
> 
> Thanks for addressing this.

Yes, it's still longer than it should be.  Android scanners are definitely much faster.  We can make more library tweaks, or perhaps something more drastic down the road.

(In reply to Jan Keromnes [:janx] from comment #6)
> P.S. Maybe wait for the optimization patches to land before merging this?

Yep, I'll depend on that one, so that we don't land this first (which would be overall slower).

	Hubert Figuiere [:hub]
	Comment 8 • 9 years ago

Have you considered using the C++ port? Either natively or through emscripten?

https://github.com/glassechidna/zxing-cpp

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 9 • 9 years ago

(In reply to Hubert Figuiere [:hub] from comment #8)
> Have you considered using the C++ port? Either natively or through
> emscripten?
> 
> https://github.com/glassechidna/zxing-cpp

This repo did not exist at the time I was looking for libraries, so it was not considered then.  I think I did not anticipate performance being so bad, either. :)

Anyway, this is at least worth investigating.  Thanks for the link!  I think we're at least in "good enough" territory with bug 1152836 plus this one.  But certainly, it could still be much better.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 10 • 9 years ago

https://github.com/mozilla-b2g/gaia/commit/4f71285ba3a3071fc0a8db9be9145a91c419f560