When decoding a stream, the decode buffer is often grown multiple times, its
byte size increasing like so: 512, 1024, 2048, etc. This patch estimates the
minimum size in advance (using the length of the encoded stream), often
allowing the smaller sizes to be skipped. It also renames numerous |length|
variables as |maybeLength| to make it clear that they can be |null|.
I measured this change on eight documents. This change reduces the cumulative
size of decode buffer allocations by 0--32%, with 10--20% being typical. This
reduces peak RSS by 10 or 20 MiB for several of them.
This avoids lots of unnecessary work when such streams are referred to via
fetch(), and so their bytes aren't subsequently read. This is a large
performance win on some files.
Now, it computes the numbers with only basic arithmetic operations, without first creating a string and then calling parseFloat.
The new function doesn't behave exactly the same as the old one.
In particular, the old behaviour was that when there was a number immediatly followed by an 'E', the 'E' was consumed. Now it's not. It allows for "glued" numbers and operators.
Also, the new function is faster and consumes less memory.
Do not throw exception when hex strings are in the wrong format
Currently pdf.js is throwing an exception for the following hex string:
`<7 0 2 15 5 2 2 2 4 3 2 4>`
The issue is that the 15 is not a valid hex character so pdf.js ends up
throwing an exception.
This diff changes the parser to process the above hex string as follow:
`70 21 55 2 24 32` (Note: the final 4 of the hex string is ignored)
replicating the behaviour of MuPDF, and doesn't throw an exception.
Jonas Jenwald
Yury Delendik
p01
fkaelberer
Rob Wu
Tim van der Meij
Nicholas Nethercote
Ophir LOJKINE
Jonas
Brendan Dahl
eug48
Mack Duan
Martin Koegler
Jon Buckley
Saebekassebil
Kalervo Kujala
gigaherz