decker-edu / decker

A markdown based tool for slide deck creation.
GNU General Public License v3.0
55 stars 13 forks source link

`decker pdf` broken #11

Open mbotsch opened 1 year ago

mbotsch commented 1 year ago

decker pdf is very unreliable at the moment. It produces broken PDFs in 30-50% in my case.

I tracked down the problem to this commit of Reveal.js: https://github.com/hakimel/reveal.js/commit/892c752a4b342206d2141ad17d1fd3a6edda3438

Most likely an async-issue in setupPDF.

salbeira commented 1 year ago

Recently re-tested this on my Linux machine and even with the revert of our Reveal.js version to "before the commit", even with clean repositories and installs I still have this issue. @monofon Does this still happen on your machine too? (Arbitrarily generating single white page pdfs).

I even did a local change to all plugins I touched for accessibility to not initialize when print-pdf is set but the issue remains, so I doubt it is related to our introduction of the inert polyfill or other features.

While typing this I remembered that several "chrome started ..." messages were posted before the first "chrome finished ..." message appeared so I tried running decker pdf with -j1 and it worked without the issue. This might be caused by running multiple chrome instances at once. Maybe a fix for this is simply enforcing -j1 as the default when using decker pdf and only increasing the job count on demand above 1.

monofon commented 1 year ago

Just tested with a fresh google-chrome-stable on Debian 11.

All PDFs seem to be fine.

salbeira commented 1 year ago

Can you tell me what your CPU and RAM specs are? This feels to me like my device has too many cores and all the chrome instances require too much RAM as a result.

monofon commented 1 year ago

Intel(R) Core(TM) i5-10600T CPU @ 2.40GHz 6 Cores 32 GB

salbeira commented 1 year ago

AMD Ryzen 5800H 8 Cores, 16 Threads 27 GiB (probably 32 GB to)

While running the decker pdf command I can clearly see all 16 CPUs spike to 100% for a short time but my memory never goes above 4 GB used so that doesn't really get us any further.

Using no -j1 though clearly still results in empty pdfs. With the flag on I never encounter the issue no matter how often I run the program.