oh, nm, I was looking at the old mocks. ignore me.

hmm...@Nirzar, @bmansurov - maybe the best thing to do then is to establish some sort of threshold for "large" and skip showing an estimate altogether to the user

@bmansurov - do we have a way of estimating page numbers?

@Niedzielski - while technically stalled, I'm marking this as open so we can get an estimate over the following week (as stalled task do not currently appear on the board by default).

In T176466#3627154, @bmansurov wrote:

It seems that the headless Chrome version of the book renderer will take longer to render a book than OCG did.

This is not necessarily true (it maybe true, but we haven't checked that). We didn't compare headless Chromium to the current OCG backend. What we did was measure if it was possible to render books with thousands of pages and the answer was a "YES" (as opposed to a "NO" from Electron). This task is here because the proposed headless Chromium backend will have to lift the load of both ElectronPdfService and OCG, thus increasing the load on servers, which is why we think the render processes maybe slow. For example, if someone is rendering a 1000 page book, and another person initiates a one-article PDF render, then the second person may have to wait because the server is busy with rendering the book. We also suppose that the current Electron backend fails so much because jobs are not queued (needs verification from someone who knows the Electron backend well).

Moving to needs analysis. @phuedx - this is issue should disappear with the new endpoint, right?

Marking as high priority based on timeline. @phuedx, @chelsyx - feel free to go down to normal if you think it's more appropriate.

Marking as stalled until completion of T176463: [Spike] Investigate libraries for post-processing without non-JS dependencies

marking as stalled until completion of T176463: [Spike] Investigate libraries for post-processing without non-JS dependencies

Moving out of sprint and marking as stalled until the completion of T176463: [Spike] Investigate libraries for post-processing without non-JS dependencies

In T176341#3626310, @phuedx wrote:

The instrumentation has been deployed, enabled, and we're receiving events at a peak rate of ~25 events/min 🎉🎉🎉

If we want to increase that rate, then I suggest a new task for increasing the bucket size (with working!). FYI it'll be a 1 pointer 😉

@Tbayer - are the enwiki and dewiki results saved in a different table from the stage0 results? If so, we may be able to delete the most recent test now and relaunch once T175918: EventLogging subscriber module in ready state but not sending tracked events is complete.

Next steps on headless Chromium:

• test rendering with single-article PDFs
• redesign workflow for book download to account for longer download times T176466: Update books workflow to account for longer render times
• investigate ways of combining headless Chromium and post-processing, look into whether we can post-process with node.js T176463: [Spike] Investigate libraries for post-processing without non-JS dependencies
• once OCG is retired and the above tasks completed, create a task investigating hardware requirements

@bmansurov - is something like this possible? If so, the will the browser notify the user when download is complete?

closing this for now. Next steps for post-processing and headless chrome to be tracked in T176463: [Spike] Investigate libraries for post-processing without non-JS dependencies

@bmansurov, @phuedx to update task description

Moving into sprint so we can start recording data asap. We can then proceed with T169732: Deploy new desktop print styles on all projects in two weeks (Oct 9)

Cool, so yeah, this would be for all projects (including the ones that don't redirect to Special:ElectronPDF currently.

@bmansurov - not I'm a bit confused. Selecting "Download as PDF" on enwiki right now redirects to the selection screen which currently is Special:ElectronPDF:

good news!

@bmansurov - no, that was our initial plan, but we would want the workflow from this task on all projects.

@Tbayer - do we still want to do 10%?

== Conclusions
Headless Chromium is able to render books with thousands of pages. It just takes a long time. We'll need machines with good CPU power if we want to speed up the render time. We'll have to work with a designer to change the UI (for example, by limiting the number of articles one can add to a book) and redo the back-end to render PDFs as queued jobs and notify the user via an email or an echo notification when their PDF is ready.

@Nirzar - is this a blocker for deploying the new styles?

Stalled due to pausing the books feature, as electron will not be our final renderer. Let's get back to this once we select a renderer.

It seems that splitting this will depend on our eventual choice of renderer. If we decide to go with headless chromium and do post-processing separately, we should pull out the styles for page numbers and toc into a separate task