mirror of
https://github.com/mozilla/pdf.js.git
synced 2025-04-20 07:08:08 +02:00
168c6aecae
I'm slightly surprised that this hasn't actually caused any (known) bugs, but that may be more luck than anything else since it fortunately doesn't seem common for Streams to be defined inside of an 'ObjStm'.[1] Note that in the `XRef.fetchUncompressed` method we're *not* caching Streams, and that for very good reasons too. - Streams, especially the `DecodeStream` ones, can become *very* large once read. Hence caching them really isn't a good idea simply because of the (potential) memory impact of doing so. - Attempting to read from the *same* Stream more than once won't work, unless it's `reset` in between, since using any method such as e.g. `getBytes` always starts at the current data position. - Given that even the `src/core/` code is now fairly asynchronous, see e.g. the `PartialEvaluator`, it's generally impossible to assert that any one Stream isn't being accessed "concurrently" by e.g. different `getOperatorList` calls. Hence `reset`-ing a cached Streams isn't going to work in the general case. All in all, I cannot understand why it'd ever be correct to cache Streams in the `XRef.fetchCompressed` method. --- [1] One example where that happens is the `issue3115r.pdf` file in the test-suite, where the streams in question are not actually used for anything within the PDF.js code. |
||
|---|---|---|
| .. | ||
| core | ||
| display | ||
| images | ||
| shared | ||
| doc_helper.js | ||
| interfaces.js | ||
| license_header.js | ||
| license_header_libre.js | ||
| pdf.image_decoders.js | ||
| pdf.js | ||
| pdf.worker.entry.js | ||
| pdf.worker.js | ||
| worker_loader.js | ||