Match the React Native throughput path with PHP - #3
Open
shanerbaner82 wants to merge 4 commits into
Open
shanerbaner82 wants to merge 4 commits into
shanerbaner82 wants to merge 4 commits into
Conversation
Every decode used to leave the phone through PHP: native event -> WebView
fetch -> a full Laravel request -> Guzzle POST on a fresh connection ->
a bridge call back into native to confirm. That is a PHP boot and a TCP
handshake per code, and it is what the benchmark ends up measuring.
`ZxingScanner::start($target, $reportUrl)` now hands the scanner the
server's /scan URL. Android and iOS POST {"value": code} there themselves
on a single persistent connection (opened before the first code) and count
a scan as soon as the reply says ok. PHP runs once to start the run and
once when RunCompleted arrives. The CodeScanned + confirm() path is still
there for apps that want to decide what counts, so RelayScan is gone from
the app.
Android talks to the socket directly: the NativePHP scaffold's
network-security config blocks cleartext for HttpURLConnection/OkHttp, a
plugin manifest cannot relax it, and the benchmark server is plain http
on the LAN.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Android: pin the AE target fps range to the camera's fastest fixed rate (60 where advertised, else 30) so a new code on the screen is captured sooner and delivered more often, and decode a 640x480 stream instead of 720p. That is plenty of pixels per module for a phone-screen QR at arm's length, zxing-cpp decodes it in a few ms, and a budget SoC can deliver it at the full camera rate (a 1440x1080 stream ran at 11 fps on a Galaxy A15). iOS: the .hd1280x720 preset settles on a 30 fps format on most iPhones. Pick the 720p format that can do 60, cap exposure at 1/250 s so a frame is not integrating for a whole 1/30 s, and restrict autofocus to near. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The elapsed time began when the camera opened, so warm-up and aiming at the screen were part of every run. It now starts when the first scan is accepted, which is the loop the benchmark is about. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Member
|
Your PR one-sidedly improves NativePHP to "cheat" being better than React Native in the following ways;
I created a follow up (#4) to also apply the same optimizations to React Native, which is super funny because now we both built native Android apps doing the same thing (ZXing). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The original version moved the report loop into Kotlin, forced a smaller/faster camera stream, and started its clock on the first accepted scan. That did not measure the same work as the React Native throughput screen.
This revision makes the Android benchmark path equivalent:
POST /reset, then start the monotonic clockPOST /scan, checks the server'sokresponse, and increments the count287c85df6f961c8efbfb5ffd736cd9457b8b890e) and the same live decoding ladder: plain scan every frame, rotation-aware fallback every fourth unsuccessful frameSame-device Galaxy A15 results with the same QR display and positioning:
That is a 1.9-second difference (about 1.4%) in this run. React Native was built as release while the NativePHP measurement was a debug build, so the result should be read as practical parity from this paired run rather than a broad framework performance claim.
Validation: