I have this problem with Chrome v68, Chromium v70, and Slimjet 19.0.9 (based on Chromium v66). They all exhibit this behaviour.

I'm trying this out on a fairly powerful desktop computer. It has never failed. Though it is really slow, so it takes a long time. After clicking Save, I have to wait a while before the file saving dialog appears.

I only have my laptop, which is a Dell 5558. A summary of my specs is attached.

As I said previously, content on www.gmbinder.com previously worked quite quickly. One of my earlier brews, https://www.gmbinder.com/share/-LJMCQ3nOH0nZbBh5zOJ, used to print preview and save quite quickly, together within 30 seconds, IIRC, in previous versions of chrome. Now takes up to 1 min 30 to print preview, and a further 30 seconds for the save dialog to appear once the save button has been clicked.

When I tested these in Chromium and Slimjet, I tested them in both in fresh profiles, with no addons or any configuration changes, so as to check if it was an addon clash.

https://www.gmbinder.com/share/-LFhhtssjN-teWCOregn spends a minute to print preview, then says print preview failed, with the save button greyed out.

https://www.gmbinder.com/share/-L3ZcUuXVydFYZAHPAg- spends 5+ minutes to print preview, and doesn't do anything else.

Thoughts?

Deleted: RJBPRIME-LAPTOP-Summary.txt 625 bytes

RJBPRIME-LAPTOP-Summary.txt 625 bytes View Download

ryuragnas@ Thanks for the issue.

Tested this issue on Windows 10 on the reported version 68.0.3440.84, latest Canary 70.0.3516.0 and M-64 build 64.0.3240.0 by following the below steps.

1. Launched Chrome and navigated to https://www.gmbinder.com/share/-L3ZcUuXVydFYZAHPAg-
2. Clicked on "Print / Generate PDF" and changed the printer name to "Save as PDF".
3. Changed the Paper size to A4.
4. Took some time for print preview to render and then after clicking on Save button, the save button is grayed out for some time but able to save the document to device.
Attached is the screen cast for reference.
The same behavior is observed on M-64 build 64.0.3240.0

Request you to check and confirm if anything is missed from our end in triaging the issue.

Thanks..

Deleted: 871678-M64.mp4 3.7 MB

	871678-M64.mp4 3.7 MB View Download

I've uploaded a video to youtube of what happens on my laptop.

https://youtu.be/sTXxNfCzXoM

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I think "Save as PDF" will work eventually if you wait long enough. There's definitely room for improvement to generate the print preview and the to-be-saved PDFs faster.

With regards to the second GMBinder link in my video, which is 118 pages, the preview fails, the Save button also does not allow clicking on when it does so. So I am unsure on what to do now.

Yes, I watched the video more carefully and noticed you changed the paper size to A4. I can get the preview process to fail. Once that fails, it is expected for the Save button to stay grayed out. I need to look at that separately to figure out why it's failing.

halcanary: For this bug, the combined time for generating the print preview and the final PDF to send to the printer roughly doubled. I bisected to https://chromium.googlesource.com/chromium/src/+log/9c79c354..2b8389a3, so the slowness may be due to https://skia.googlesource.com/skia.git/+/82591144 ?

thestig@, do you have before and after PDFs for me to look at?

I have one saved copy, but I'm not sure if it was a before or after PDF. It's ~128 MB though. Do you want to generate it for yourself? If you run:

tools/bisect-builds.py -a linux64 -g 558089 -b 558095 --verify-range

That will download and launch the good / bad builds.

The print preview failure issue has a different root cause. I filed bug 872935 for that.

Any update on this? Chrome Details:

```
Google Chrome : 71.0.3578.80 (Official Build) (64-bit) (cohort: 71_Win_80)
Revision : 2ac50e7249fbd55e6f517a28131605c9fb9fe897-refs/branch-heads/3578@{#860}
OS : Windows
JavaScript : V8 7.1.302.28
Flash : 32.0.0.101 C:\Users\Danno\AppData\Local\Google\Chrome\User Data\PepperFlash\32.0.0.101\pepflashplayer.dll
User Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36
Command Line : "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --disable-pushstate-throttle --enable-fast-unload --use-simple-cache-backend=on --reduced-referrer-granularity --save-page-as-mhtml --enable-smooth-scrolling --top-chrome-md=material-refresh --enable-features=GdiTextPrinting,NewTabPageBackgrounds,NewTabPageCustomLinks,NewTabPageIcons,NewTabPageUIMd,NupPrinting,ParallelDownloading,PdfIsolation,SingleTabMode,TranslateUI,UsePdfCompositorServiceForPrint --flag-switches-end
```

Revised comment: I'm not having this exact problem currently, but it is still slow to render the file when using Save to PDF. For a 22 page document, it takes a couple of minutes still to render the Print Preview. Saving after it renders is near instantaneous, but as I said in comment 5 of this bug report, it didn't take this long for older versions of Chrome (pre-ver. 64).

Testing https://www.gmbinder.com/share/-L4gNPnpEQ4Y6z7dAC5B with https://github.com/henrypp/chromium/releases/tag/v52.0.2743.120-r394939-win64, from when I click "Print / Generate PDF" to set the document to pages 1 - 39, to print preview rendering takes 10 seconds. It takes a further 10 to 15 seconds from clicking the save button after it renders for the "Save As" window to appear.

Testing https://www.gmbinder.com/share/-L4gNPnpEQ4Y6z7dAC5B with https://github.com/macchrome/chromium/releases/download/v72.0.3617.0-r609662-Win64/chromium-nosync.zip, from when I click "Print / Generate PDF" to set the document to pages 1 - 39, to print preview rendering takes nearly 3 minutes!! Clicking the "Save As" button after this takes about 5 seconds to save.

The increase of time for rendering from version 52, to version 72, is 1700%. This is with both chromium versions having cleared cache, no extensions, and no flags.

Could this be looked at further? 

re: comment 13 - here's the before and after PDFs for https://www.gmbinder.com/share/-L3ZcUuXVydFYZAHPAg- printed to Letter size paper. https://drive.google.com/file/d/1CKuyDB-WbEMI9alHsPM3QtaBfulcFaNR/view?usp=sharing

Further to my own testing, has found that version v60.0.3112.113-r474897-win64 of Chromium seems to be the sweet-spot for using GMBinder. I've tried the following versions (tests done with chrome-nosync of each version and Profile folder as a subdirectory of install folder, with --user-data-dir= flag used to select each versions Profile subdirectory):

v52.0.2743.120-r394939-win64 (incorrect font rendering)

v56.0.2924.87-r433059-win64 (renders A4 incorrectly, pages slide up in print preview)

v57.0.2987.133-r444943-win64 (renders A4 incorrectly, not as bad as v56.0.2924.87-r433059-win64)

v58.0.3029.110-r454471-win64 (renders A4 incorrectly, not as bad as v57.0.2987.133-r444943-win64)

v59.0.3071.115-r464641-win64 (failed to load webpages in general)

When I use v60.0.3112.113-r474897-win64, it appears to render correctly, fast, and most of all, doesn't fail to load print preview.

Can someone shed some light on what changed between v60.0.3112.113-r474897 and current, with regards to Saving to PDF?

thestig@, I'm not a chrome guy: what does "r558089" mean?  how do I translate that into a git commit I can look at?

Also, a meta-comment about these bugs:

It's not clear to me where the slowdown is happening.  *If* the problem is in SkPDF, I can do something about that, if I have the time:

  1) Make SkPDF more efficient.  I've got some ideas, it just takes time to implement the refactoring

  2) Drop some effects to save time.

  3) Work on deflate.  It's the elephant in the SkPDF pipeline:

    a) Optionally, drop down to the "fast" setting on zlib's deflate.

    b) Optionally, skip calling deflate at all.  There will be a giant memory cost.  Can chromium buffer to disk instead of memory?

    c) Introduce some threading to SkPDF.  We can deflate each object in its own thread and then paste them together in the end.  This might be much faster on multi-core machines.  How many threads does Chrome want to give us?  


     

re: comment 20 - r558089 (<-- this will get linkafied) is the same as https://crrev.com/558089 . It's also in the commit message on the Cr-Commit-Position: line.

re: comment 19 - Chromium added a PDF Compositor, so the way we call Skia changed. Improving the PDF Compositor to work better with large documents is bug 872935.

But for this bug, our focus is on making Skia faster. As I said in comment 14, if you compare r558089 and r558095, the latter is much slower, and only Skia changed in that range.

thestig@,

https://skia.googlesource.com/skia/+/9a3f5541542 added a new experimental feature to SkPDF: worker threads.  

Take a look at the API change: https://skia.googlesource.com/skia/+/9a3f5541542%5E%21/#F2

Do you want to experiment with this in Chromium?

I can give it a shot. So it sounds like we cannot avoid the canvas scaling work? Instead we will try to do it faster by utilizing more cores?

Using ChrLauncher 2.5 to download dev-clang-nosync version Chromium 73.0.3667.0 (Official Build) (64-bit), still exhibits slow Save As PDF export. Using the first link in my first post, it still fails to render in a reasonable time. It takes 271 seconds to render Print Preview, but 5 seconds to complete Save As PDF. Video Link: https://www.youtube.com/watch?v=2_CiNpms1ok

Using Chromium v60.0.3112.113-r474897-win64 from https://github.com/henrypp/chromium/releases, using --user-data-dir=.\profile --no-default-browser-check --allow-outdated-plugins in it's windows target line, I've uploaded a video to my youtube channel, being a recording of how long it takes to render and save the first GMBinder link to my laptop. Video Link: https://www.youtube.com/watch?v=Vv7vVwWa1DQ

It takes 35 seconds to complete Print Preview, and a further 133 seconds to complete Save As PDF.

Using Chromium v62.0.3202.94-r499098-win64, using the same settings as the previous paragraph, it takes 122 seconds to complete Print Preview, and a further 110 seconds to complete Save As PDF. Video Link: https://www.youtube.com/watch?v=MhW-QOh6YJ0

Could this be looked at further? Not sure if I can do anything further, but I am hoping this can be resolved in a future update.

thestig@,

"So it sounds like we cannot avoid the canvas scaling work?"

You could always set SkPDF::Metadata::fRasterDPI to a smaller number.  You've tried 72 and 300.  How about 144 or 150 as a compromise?