Show HN: FastQR – A Fast QRCode Generator Supporting Batch Processing
I'd like to share FastQR (https://github.com/tranhuucanh/fastqr), a high-performance QR code generator written in C++. This is my first open-source project, and I'm excited (and a bit nervous!) to share it with you all.
What it is: - A fast CLI tool and library for generating QR codes - Written in C++ with bindings for Ruby, PHP, and Node.js - Full UTF-8 support (works great with Vietnamese, Japanese, and other languages) - Supports custom colors, logo embedding, and precise size control - Pre-built binaries included – no need to install dependencies separately
Why I built this: - I needed a QR code generator that was fast, supported UTF-8 properly (especially for Vietnamese text), and could be easily integrated into different languages. Most existing solutions were either slow or had poor Unicode support.
Performance: - Generating 1000 QR codes (500x500px): ~0.37 seconds
Tech stack: - C++ core using libqrencode and libpng - Language bindings for Ruby, PHP, and Node.js - Precompiled binaries for easy installation
This is my very first open-source project, so I'm sure there are things that could be improved or bugs I haven't caught yet. I'd really appreciate it if you could try it out and share your feedback. If you find any issues or have suggestions, please open an issue on GitHub – I'll do my best to fix them quickly.
Any feedback, criticism, or suggestions would be greatly appreciated. Thanks for taking the time to check it out!
Neat! Could you publish a few example QR codes in the readme?
My understanding is qr codes various levels of redundancy (error correction) in the image. When you're comparing your code with other libraries, do they have the same level of error correction and byte length?
Thanks for the great feedback! You're absolutely right - I'll add QR code examples for each error correction level to the README to make the comparisons clearer.
Regarding error correction levels: yes, all benchmarks are done with the same parameters (error correction level and byte length) to ensure fair comparisons. I'll make this more explicit in the README and include a detailed comparison table showing the error correction levels used for each benchmark.
I appreciate you pointing this out - transparency in benchmarks is really important!