Significant textLayer performance regression after PR 15722

[Snuffleupagus]

Attach (recommended) or Link to PDF file here: https://github.com/mozilla/pdf.js/files/1522715/wuppertal_2012.pdf

Configuration:

• Web browser and its version: N/A
• Operating system and its version: N/A
• PDF.js version: Any version after PR [api-minor] Refactor the text layer code in order to avoid to recompute it on each draw #15722
• Is a browser extension: N/A

Steps to reproduce the problem:
Open the referenced PDF document, and measure the time it takes for the textLayer to finish rendering.

What is the expected behavior? (add screenshot)
The textLayer should render in ~7 seconds (or better).

What went wrong? (add screenshot)
The textLayer takes ~140 seconds to render.

Note that if I add this.div.hidden = true after the following line performance is back to normal, although it's not clear to me if that's a correct/safe solution in general.
The reason that this regressed is presumably that we used to use a DocumentFragment for building the textLayer, but now we we're using a regular div which is immediately attached to the DOM thus causing lots of invalidation during layout.

/cc @calixteman

[calixteman]

Considering:

pdf.js/web/text_layer_builder.js

Line 128 in cb212b2

this.show();

I think the hidden thing is an oblivion.

[calixteman]

Very good catch !
On my workstation (which is supposed to be a good one): ~206s without the patch vs ~10s with.

[calixteman]

Unrelated to this issue but do you think that it could be interesting to measure the strings in the worker ?

[Snuffleupagus]

Note that I found this issue when I noticed that zoom-performance was now extremely poor for that PDF document (zooming was never fast but now it was really bad).
Initially I figured that we somehow regressed general rendering performance, but couldn't understand how, so it took me a little while with both mozregression and git bisect to narrow down the offending patch. Then it took some more time to figure out why it regressed and how to possibly fix it...

---

Unrelated to this issue but do you think that it could be interesting to measure the strings in the worker ?

Maybe, if it measurably improves performance and isn't really complicated to implement. (I'm assuming that we'd use OffscreenCanvas, which unfortunately means that we'd still need to keep the old code in the src/display/text_layer.js file as a fallback.)