Investigate how to continue the streams API work

[timvandermeij]

The project from https://github.com/mozilla/pdf.js/projects/4 is completed, but it's likely that we can get additional speed-ups by using the streams API in more places. The following notes were left on the project and may be used for further improvements:

• Wrapper for xhr: We can create a Streams API wrapper for xhr to incrementally read and write data.
• Streams API with MessageHandler: MessageHandler is used for sending OperatorList data from worker thread to main thread. As sending of data only happens when the whole data is parsed, this may cause time and memory inefficiency.

[apoorv-mishra]

Anyone working on this currently @timvandermeij ? If not, I would like to pick it up.

[Snuffleupagus]

• Wrapper for xhr: We can create a Streams API wrapper for xhr to incrementally read and write data.

Given that Fetch is usually used/preferred to XHR in PDF.js now, the question is if doing that is actually worthwhile at this point in time!?

• [...] As sending of data only happens when the whole data is parsed, this may cause time and memory inefficiency.

Looking at RenderPageRequest/RenderPageChunk in the API/Worker, and also how the OperatorList is implemented in e.g.

pdf.js/src/core/operator_list.js

Lines 575 to 583 in 06b253d

	if (this.messageHandler) {
	if (this.weight >= CHUNK_SIZE) {
	this.flush();
	} else if (this.weight >= CHUNK_SIZE_ABOUT &&
	(fn === OPS.restore || fn === OPS.endText)) {
	// heuristic to flush on boundary of restore or endText
	this.flush();
	}
	}

this part is actually already supported, since the API/viewer have supported incremental rendering ever since PR #3461 (back in 2013). Obviously it's certainly possible, and even likely, that this can be made even more efficient, in various ways, by also utilizing the Streams API here as well.
Although I'm not really convinced that this would be a good beginner bug though...

[timvandermeij]

Closing since, as indicated above, most of this is already done and the remainder is not really actionable. If we have a clear indication of a spot where the streams API would be beneficial, a separate issue should be opened.