1668400 - Optimization: avoid needless reflow for page-range changes

Status: NEW

(Core :: Printing: Output, task)

Description

[Daniel Holbert [:dholbert]]

[Background]
As part of the [print2020] tab-modal-printing project, we handle page ranges at reflow-time instead of at print time.

To do this, we reflow all pages as if they were going to be printed, and then we group unprinted nsPageFrame objects into the child list of an adjacent PrintedSheetFrame, and we tag them with a flag that prevents them from painting. This helps maintain our invariants around next-in-flow tree hierarchies; and it allows for us to elegantly lay out non-contiguous pages from different print ranges on a single sheet when the pages-per-sheet feature is being used. (The other pages will be present in the PrintedSheetFrame's child list, but are simply un-painted & don't have any geometric area reserved for them on the sheet.)

[The issue]
Ideally, if the user makes a dynamic change to the page-range (editing the textfield in the print dialog), we would like to handle that by pushing nsPageFrames around between PrintedSheetFrames (without needing to touch the content, because the layout inside of each page is not actually changing). Unfortunately we can't do that right now, because nsPageSequenceFrame doesn't handle incremental reflow - it just recomputes its transform and returns.

We should fix this so that nsPageSequenceFrame does support incremental reflow, and we should be sure that page-range-adjustments trigger an incremental reflow instead of rebuilding the frame tree from scratch (as I am 99% certain they currently do).

(We shouldn't try to fully support incremental reflow here, because we largely don't need to -- we could preserve the "bail out early" behavior at the level of the nsPageFrame, perhaps via PrintedSheetFrame promising to never invoke ::Reflow on a nsPageFrame child that has been previously reflowed.)

Comment 1

[Daniel Holbert [:dholbert]]

(This may help us with bug 1668230, though I suspect something else may be the primary performance-hurting culprit there, per bug 1668230 comment 3 and bug 1668230 comment 4.)