1782597 - Lazily initialize PageValueProperty on nsIFrame

Status: RESOLVED FIXED

(Core :: Layout, enhancement, P2)

Description

[Emily McDonough [:alaskanemily]]

Currently when named pages are enabled, every nsIFrame gets a PageValueProperty. This is wasteful both because many/most web pages do not use named pages, and because when they are used only a small fraction of all frames have the page property set to something meaningful (ie, not auto).

We should lazily/sparsely initialize this property to only be present on frames where it communicates information. If a document does not use named pages at all, then we should not be creating PageValueProperty structs for all of its frames. Ideally we would create none, or possibly just one for the document root.

The simplest solution would be to maintain the current behavior, but only begin populating this value once we see a page value that is set. This would still result in many PageValueProperty being created for this example, but would mean that if a document doesn't use named pages at all then it would still not have any extra allocations performed.

Some situations we need to consider:

1. Currently, our implementation of named pages uses a missing PageValueProperty to indicate that a frame should not participate in named page fragmentation at all (for instance, combo box children, floats, display: none, etc). We will need to handle this situation in another way if this property being missing instead indicates auto.

This would, however, still work if we chose just to begin populating PageValueProperty once we found a page-name. This would mean that when a document did not use page-name at all, it would use the same logic to just skip all frames.

2. Very tall frame-trees with page-name set on a very early ancestor of most frames.
   As an example:
   <div style="page:a"><div><div><div><div><div><div><div><div><div><p>Page a</p><p style="page:b">Page b</p></div></div></div></div></div></div></div></div></div></div>

While we are investigating solutions, this would be a nice case to improve. Ideally, the first p element should not need to walk back up the frame tree to determine what its auto value is. For this specific case, it also seems that we might be able to share one PageValueProperty struct for all the nested div, which would at least reduce the number of duplicate structs allocated.

This would also be complicated by the situation where another div follows the outermost div, in which case we would need to propagate the end page value of b up the entire frametree. This might be unavoidable (or not worth avoiding) in a situation like this.

Comment 1

[Emily McDonough [:alaskanemily]]

Attachment: Bug 1782597 Part 1 - Store auto page value on each frame when in a paginated context.

Comment 2

[Emily McDonough [:alaskanemily]]

Attachment: Bug 1782597 Part 2 - Use null to indicate page value equal to the auto value for CSS named pages

This applies both to the individual mStartPageValue and mEndPageValue fields
of the nsIFrame::PageValues struct, and for the nsIFrame::PageValuesProperty
being null to indicate both mStartPageValue and mEndPageValue are auto.

Fetching this is handled by nsIFrame::GetStartPageValue and
nsIFrame::GetEndPageValue, which also ensure the use of first-in-flow frames.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cbed1d1d6714
Part 1 - Store auto page value on each frame when in a paginated context. r=dholbert,emilio
https://hg.mozilla.org/integration/autoland/rev/27e7a85b0ca6
Part 2 - Use null to indicate page value equal to the auto value for CSS named pages r=dholbert

Comment 4

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/cbed1d1d6714
https://hg.mozilla.org/mozilla-central/rev/27e7a85b0ca6