jbig2dec VS cpmulator

> The worst offender (so far) is the JBIG2 format (several major libraries, including jbig2dec), a very popular format that gets EXTREMELY high compression ratios on bilevel images of types typical to scanned pdfs. But: it's also a format that's pretty slow to decompress—not something you want in a UI loop, like a PDF reader is! And, there's no way around that—if you look at the hot loop, which is arithmetic coding, it's a mess of highly branchy code that's purely serial and cannot be thread- nor SIMD- parallelized.

Looking at the jbig2dec code, there appears to be some room for improvement. If my observations are correct, each segment has its own arithmetic decoder state, and thus can be decoded in its own thread. The main reader loop[1] is basically a state machine which attempts to load each segment in sequence[2], but it should not need to. The file has segment headers which contains the segments offsets and sizes. It should be possible to first read this header, then spawn N-threads to decode N-segment in parallel. Obviously, you don't want the threads competing for the file resource, so you could load each segment into its own buffer first, or mmap the whole file into memory.

[1]:https://github.com/ArtifexSoftware/jbig2dec/blob/master/jbig...

[2]:https://github.com/ArtifexSoftware/jbig2dec/blob/master/jbig...

I still haven't found an tolerably fast PDF reader, and I'm permanently miserable with that file format. The example in OP works great, but that's only an "easy, modern" PDF made up of text. There's still nothing adequate (mupdf/mutool included) for the common case of scanned-page PDF's.

The root problem isn't an easy performance fix: it's that a very popular PDF image compression format, JBIG2 [0], is unlike modern formats slow in decompression as well as compression. Here's the decompress hot loop [1,2] from libjbig2dec.so, which MuPDF calls out to. I isn't thread- or SIMD- parallelized, and I suspect that it isn't possible at all. There's just no easy way forwards in the near future—other than "buy faster CPU's".

[0] https://en.wikipedia.org/wiki/JBIG2

[1] https://github.com/ArtifexSoftware/jbig2dec/blob/master/jbig...

[2] https://github.com/ArtifexSoftware/jbig2dec/blob/master/jbig...

A while back I wrote a game in assembly, for CP/M. Since I have a single-board Z80-based computer on which I can run it.

I later ported the game to the ZX Spectrum, because that was a fun challenge, and I only needed a few basic I/O operations - "write to screen", "read a line of input", etc, etc.

It occurred to me that I could reimplement the very few CP/M BIOS functions and combine those implementatiosn with a Z80 emulator to run it "natively". So I did that, then I wondered what it would take to run Zork and other games.

Slowly I've been reimplementing the necessary CP/M BDOS functions so that I can run more and more applications. I'm not going to go crazy, anything with sectors/disks is out of scope, but adding the file-based I/O functions takes me pretty far.

At the moment I've got an annoying bug where the Aztec C-compiler doesn't quite work under my emulator and I'm trying to track it down. The C-compiler produces an assembly file which is 100% identical to that produced on my real hardware, but for some reason the assembler output from compiling that file is broken - I suspect I've got something wrong with my file-based I/O, but I've not yet resolved the problem.

TLDR; writing a CP/M emulator in golang, and getting more and more software running on it - https://github.com/skx/cpmulator