Print preview area not showing one page at a time |
|
Issue descriptionChrome 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.
,
Jun 2 2018
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.
,
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 |
|
Comment 1 by thestig@chromium.org
, Jun 2 2018