Enable WebGL by default?

[timvandermeij]

I was wondering if WebGL is considered stable enough to be enabled by default. It makes some PDFs render much faster and it has been off by default for a while now, so we have had quite some time to test it.

If we decide to enable WebGL by default, we should not forget to update https://github.com/mozilla/pdf.js/blob/master/extensions/chromium/preferences_schema.json#L39 as well.

/cc @yurydelendik
/cc @Snuffleupagus (because IIRC you were testing WebGL too)

[Snuffleupagus]

There is #4286 (comment), which may be relevant.

Edit: I should note that I've been using WebGL ever since it was introduced, and I've yet to come across even a single instance of bad rendering (or worse performance) on Windows.

[yurydelendik]

We need to add testing for that. I guess botio has to be forced to support/simulate webgl in some sense.

[jqnatividad]

Are there any benchmarks as to how fast pdf.js is with/without WebGL?

Along those lines, has the team considered adding a complex/showcase PDF in the distribution that not only exercises & shows off PDF.js capabilities, but can be a standard way to get users to benchmark and report problems using a standard pdf?

I'm afraid the current demo file is just too simple.

And going back to WebGL, if its enabled by default, what would happen on a browser that doesn't support WebGL? Will it just fallback to not using WebGL?

[timvandermeij]

@jqnatividad That is exactly what we will need to look into, especially the fallback.

[yurydelendik]

Are there any benchmarks as to how fast pdf.js is with/without WebGL?

@jqnatividad see #4286

On my computer:

https://bug793542.bugzilla.mozilla.org/attachment.cgi?id=663870#pdfBug=Stats&webgl=true

Rendering takes 2788ms vs 3821ms (w/webgl=false). Please notice that this speed up is visible only for certain PDFs (in this case with smask operations)

And going back to WebGL, if its enabled by default, what would happen on a browser that doesn't support WebGL? Will it just fallback to not using WebGL?

It will fallback to regular behavior.

[yurydelendik]

I guess right now we are trying to decide "is it worth to take a risk to increase chance of breaking stuff for small amount of document on some platforms to gain some performance for them?". Also only half of the computers on the web has properly functioning video drivers for webgl AFAIK.

[Snuffleupagus]

Also, before we even consider enabling WebGL by default, I think that it would be necessary to be able to run the tests (on the bots) with WebGL enabled.
Otherwise it's way too easy for "trivial" breakage to occur, as e.g. PR #6354 shows.

[Snuffleupagus]

Given the points mentioned in #5161 (comment), especially the risks, should we simply close this as WONTFIX now (since there's been no additional WebGL support added in the meantime)?

[timvandermeij]

In a sense yes, but if we choose not to continue with WebGL, shouldn't we just remove it altogether? Keeping it around if we don't intend to use it only seems like a maintenance burden to me...

[NawarA]

This question was asked in 2014. Its now ~2020 and WebGL has become standardized.

Back then, you observed a 37% performance boost by flipping a switch. That's huge.

On the web, performance matters.

Whatever you can do to speed this library up, do it. 🚀

[Snuffleupagus]

Back then, you observed a 37% performance boost by flipping a switch. That's huge.

You need to remember that the performance increase mentioned was/is limited to documents with specific features, e.g. certain Soft Masks and Patterns, but for most PDF documents there's nothing gained by the current WebGL implementation.

Furthermore, as was also mentioned above, there's most definitely an increased risk of rendering issues caused by e.g. bad/outdated graphics drivers.

[Snuffleupagus]

Given that nothing really has changed here, should we now do what #5161 (comment) suggests and simply remove the unused WebGL implementation?

Note that, as of now, it's neither used, tested, and/or maintained; and thanks to version control it also should be (reasonably) easy to restore the code if needed in the future.

[timvandermeij]

I'd say we go for the removal. The WebGL implementation never really got out of the experimental phase and nowadays rendering engines/PDF.js itself is much faster, which was the original reason for its implementation. It's only a small subset of documents that actually benefit from it, and especially since we never really tested it it seems better to just remove it. If need be it can always be recovered from Git.

[LifeIsStrange]

I have seen many reports of PDF.js being to slow on complex PDFs. WebGL is ubiquitous in 2021-2022 and simply being too slow for many PDF use cases is a net regression. It does not promote accessibility, it regress it. It could have stayed in experimental state, that would still have been better than removing it, and if there was major limitations (there wasn't) external users could have made a pull request. And do not wrongfully claim it is not used, this is totally wrong, the google chrome PDF.js which has more than 1000000 users easily expose the option to enable it so many users have tried it in the wild and some probably depend on it.