Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Consider a Streamlined/Slimmed-down Version 2.0

See original GitHub issue

Type of issue

[ ] Bug
[ ] Question (e.g. about handling/usage)
[X] Request for new feature/improvement

Expected Behavior

Modern/lean/minimal .NET QRCoder v2.0 library
Zero dependencies
Easy to integrate cross-plat/Docker

Current Behavior

Dependency on System.Drawing.Common causes cross-plat/Docker issues (libgdiplus)
System.Drawing not really ideal for server based scenarios
Locked into legacy design/public API for back-compat reasons
Some degree of code bloat as code has aged

Possible Solution = QRCoder v2.0

Cut some legacy cruft (support netstandard2.0+ only)
Cleanup public API surface (flexibility to consider new designs)
Remove System.Drawing.Common dependency completely
Separate Payloads from QRCode generation (separate package maybe?)

Rationale

Fresh start to target modern .NET platforms/scenarios (netstandard2.0+)
Core logic/class/project structure can largely be reused
Different/new designs/optimizations can be explored.
Several existing renderers already have no dependency on System.Drawing
Other renderers could potentially be refactored to remove System.Drawing dependency.
- Does Base64QrCode really need to use Bitmap class? Can it instead work with raw bytes from PngByteQrCode? (not sure, I’m actually asking…)
- Do simple System.Drawing structs (Size Color) really need to be used?
  - Maybe remove from public signatures (string instead of Color) or maybe roll similar custom structs as an implementation detail?
Not all consumers need Payloads - maybe separate into separate package (at least more than one file 😉 ).

In my mind, it wouldn’t be a huge divergence from the current codebase - just mostly stripping out System.Drawing. Which would likely impact the embedded icons feature. Maybe layer a separate package (that depends on System.Drawing) on top of the “Core” package - so consumers can ‘light up’ features they need?

Issue Analytics

State:
Created 3 years ago
Reactions:6
Comments:27 (6 by maintainers)

Top GitHub Comments

2reactions

georgefstcommented, Feb 9, 2021

Any chance of a resolution here? @PhonicUK’s fork is the only QR library I’ve successfully managed to import in to a cross-platform Unity project, so I’d love to see something like that become more official.

2reactions

CJPNActualcommented, Jun 4, 2020

@csturm83

Another update (AMD 3900X):

V1(L): 25x faster @ 76μs/code

V40(H): 77x faster @ 5.85ms/code

Top Results From Across the Web

QRCoder

Consider a Streamlined /Slimmed-down Version 2.0 $ 0 ... Found conflicts between different versions of "System.Drawing.Common" that could not be resolved.

Slim down engine source build? - C++

I'm currently compiling the engine from source that I forked on GitHub. I would like to slim down the engine compile time and...

Ooze Twist Slim Pen 2.0 Review: Your New and Improved ...

It's still just as slim, but now with a bit more streamlined design on top. The Twist Slim 2.0 has two modes; button...

Cybersecurity Maturity Model Certification (CMMC) v2.0 ...

A new, slimmed down version of the CMMC is poised to take effect, and like the first time, integrators will need to be...

Think Tank Photo Shape Shifter V2.0 Review

The Shape Shifter Version 2.0 exemplifies these traits with its ample storage space, comfortable shoulder and back padding, and ability to ...