Daniel Micay
Daniel Micay
The non-random implementation is quite fast already and the only reason we don't manually unroll the loop is because the compiler generates code that's as good or better from this....
Ideally, we would have an implementation that is faster and does uniform random choice everywhere, not only modern x86_64.
It would be nice to at least do one major release soon where there's a GitHub release and the npm / Maven releases are updated to be in sync with...
We've tested with a relatively new snapshot but we're stuck using 20.6.30 for CI until there's a new release we can easily reference there. I don't care enough about HTML...
Can you describe what you mean?
I don't think we want this for the PDF Viewer app by default. It make make sense as an optional or a special mode to avoid ending up with any...
We can support zooming out further but it's unrealistic to support zooming in further due to how much memory is used by HiDPI rendering.
The reason it uses a lot of memory is because we currently always use HiDPI rendering unlike most other PDF Viewers which are using scaling up pixels 2x or 4x....
It's planned.
Updating the PDF rendering engine code may resolve this... but that may require a lot of work due to upstream issues that were encountered last time it was attempted.