New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 848326 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Print preview area not showing one page at a time

Project Member Reported by xlou@chromium.org, May 31 2018

Issue description

Chrome Version: 69.0.3446.0 (Developer Build) (64-bit)

What steps will reproduce the problem?
(1) Build tip of the tree,
(2) using GDB to start chrome and open a website,
(3) start another gdb session and attach process to PdfCompositor service,
(4) start another gdb session and attach process to Pdf Plugin,
(5) ctrl+p to start print preview mode,
(6) step through CompositePageToPdf, CompositeToPdf, CompositeDocumentToPdf from the step (3) debug session,
(7) step through PDFiumEngine::AppendBlankPages, PDFiumEngine::AppendPage from the step(4) debug session.


What is the expected result?
Print preview area show show the first page once AppendPage is called.

What happens instead?
Print Preview area didn't show any page until after CompositeDocumentToPdf is called.

 
- It is not clear what is being printed. I assume it has to be a multi-page HTML document?
- It's not clear what exactly is happening in step 6 and step 7. It sounds like one has to set some breakpoints first. Once breakpoints are set, does all of step 6 happens before step 7? Please better explain the sequence.
I'm not using gdb. Instead, I just added LOG statements in when the following relevant methods get called, with page number values:

PrintRenderFrameHelper::PreviewPageRendered() (renderer)
PdfCompositorImpl::CompositePageToPdf() (compositor)
PrintPreviewDataStore::SetPreviewDataForIndex() (browser)
PrintPreviewDataStore::GetPreviewDataForIndex() (browser)
PDFiumEngine::AppendBlankPages() (plugin)
OutOfProcessInstance::PreviewDocumentLoadComplete() (plugin)

Then I print previewed https://en.wikipedia.org/wiki/Football, which is a ~30 page document, and looked at the log to visualize the sequence of events. I see this order of calls, which I have annotated:

PreviewPageRendered 0 <-- [A] renderer goes first.
CompositePageToPdf 0 <-- [B] compositor needs renderer data, so it's always after [A].
PreviewPageRendered 1
PreviewPageRendered 2
CompositePageToPdf 1
SetPreviewDataForIndex 0 <-- [C] browser needs compositor data, so its always after [B].
PreviewPageRendered 3
PreviewPageRendered 4
SetPreviewDataForIndex 1
CompositePageToPdf 2
...
PreviewPageRendered 28
CompositePageToPdf 26
SetPreviewDataForIndex 25
PreviewPageRendered 29
...
GetPreviewDataForIndex 0 <-- [D] browser sends the data from [C] to the plugin.
PreviewPageRendered 30 <-- [E] renderer finishes rendering all pages.
CompositePageToPdf 28
SetPreviewDataForIndex 27
CompositePageToPdf 29
SetPreviewDataForIndex 28
AppendBlankPages <-- [F] plugin finishes loading the single page PDF in [D] as the first page, appends blank placeholders pages.
GetPreviewDataForIndex 1 <-- [G] browser sends the second page to the plugin, after [F].
CompositePageToPdf 30 <-- [H] compositor finishes compositing individual pages after [E].
SetPreviewDataForIndex 29
SetPreviewDataForIndex 30 [I] browser finishes receiving all the individual pages after [H].
PreviewDocumentLoadComplete 1 <-- [J] plugin has finished loading the second page.
GetPreviewDataForIndex 2
PreviewDocumentLoadComplete 2
...
GetPreviewDataForIndex 13
PreviewDocumentLoadComplete 13
GetPreviewDataForIndex 14
PreviewDocumentLoadComplete 14
CompositeDocumentToPdf <-- [K] compositor starts compositing a complete PDF.


So from what I'm seeing:
- the renderer / compositor / browser are working in parallel to generate single page PDFs
- at some point after the first page is available [C], the plugin loads and start doing work. [D]
- the plugin is doing work in parallel to the other processes. [D] and [G] happens before [E], [H] and [I].
- the plugin is requesting the first page [D] before CompositeDocumentToPdf() [K] gets called.
- the plugin is requesting the second page [G] before CompositeDocumentToPdf() [K] gets called.

Comment 3 Deleted

Comment 4 by xlou@chromium.org, Jun 3 2018

In Step (3): set breakpoint at CompositePageToPdf, CompositeDocumentToPdf, and CompositeToPdf, and stepped through each breakpoints, sometimes I used command "c" to get to the next breakpoint quickly.

In Step (4): set breakpoint at AppendBlankPages, AppendPage, and stepped through or "continue" to the next breakpoint.

I actually also started a gdb session to attach to the tab process that opens the website under test (I used wenxuecity.com, because my favorite website marketwatch.com tab crashed everytime I tried to get to preview mode, so did yahoo.com and cnn.com, I can try the website you tried Monday).  The breakpoint point I set here are at CreatePreviewDocument, and PreviewPageRendered.

What I saw was after PreviewPageRendered called, breakpoint in step (3) process stopped at CompositePageToPdf, and after that step completed, breakpoint in Step (4) process stopped at AppendBlankPages.  The second cycle hit breakpoint PreviewPageRendered, CompositePageToPdf, and AppendPage sequentially.  At this point, the print preview area should have shown the available pages.  However I didn't see available pages in preview area until eventually CompositeDocumentToPdf was called and finished.

I agree that the plugin is doing work in parallel if there are pages available to be processed, otherwise it is waiting for work to come.  Actually all three of them, the renderer, the plugin, and the PdfCompositor are working in parallel if each of them has work to do.

Sign in to add a comment