316089 - Pre-parsing/partial pre-rendering

Status: RESOLVED INVALID

(Core :: Layout, enhancement)

Description

[John R. Moser]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051107 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051107 Firefox/1.5

Gecko and Firefox 1.5 now store the pre-rendered pages in memory to make back/forward much faster.  This is okay, but it can use a lot of memory; on the other hand, it's very fast.  It would not, of course, be appropriate to pre-render everything fetched via pre-fetching; although this could be an interesting feature.

A pre-parsing or partial pre-rendering mechanism may be interesting, however.  Parsing is very complex traditionally; pre-parsing would store a representation of parsed HTML or XML and then be passed to the rendering subroutines to be rendered fully.  This would be analagous to using an internal tree representation of a script language, rather than parsing in real time.

The pre-parsed representation should probably carry with it formatting specifics instead of a flat representation of the original markup.  For example, the below three examples of markup would all be represented in the same way once parsed.

  <b>foo</b> <span style="font-weight: bold;">bar</span>
  <span style="font-weight: bold;">foo</span> <b>bar</b>
  <b>foo</b> <b>bar</b>

It may also be good to define hard and soft layout specifics for images.  Images with width and height specifiers, for example, will have a hard specific; while images without them will be prefetched, checked for dimensions, and given a soft-specific.  At render time, the soft specific can change; but initially the page will be lain out with text adjusted as directed.  Soft specifics may also be used to specify the predicted area that rendered text will occupy based on the fonts used.

Hopefully this sort of pre-parsing would take up much less memory than pre-rendering would, yet still manage to give layout and formatting information about text and images so the page can be more quickly rendered than if it was just parsed from scratch.  This may be a way to reduce memory usage for back-button cache, as well as allow feasible pre-fetch pre-parsing.

Reproducible: Always

Steps to Reproduce:

Comment 1

[John R. Moser]

Remarked this to core, as it has to do with Gecko.  Target is the future, though this could be made into a more visible goal if somebody can produce some sort of technical evidence that this would actually be a good way to handle pre-rendering without a full copy of the rendered page in memory.

Comment 2

[Phil Ringnalda (:philor)]

roc says "really nothing to do with the View Rendering component" so Layout for lack of a Core:General.

When you move a bug, if you choose "Reassign bug to default assignee..." then you increase the odds of finding that out in a few days, instead of a few months.

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Given my knowledge of the algorithms used to lay out Web pages and the performance hotspots in those algorithms, I don't think this bug report makes any sense.  I suggest marking invalid, but apparently roc saw it and didn't think so.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I didn't really read it, to be honest.

> For example, the below three examples of markup would all be represented in the
> same way once parsed.
>
>  <b>foo</b> <span style="font-weight: bold;">bar</span>
>  <span style="font-weight: bold;">foo</span> <b>bar</b>
>  <b>foo</b> <b>bar</b>

That won't work because those aren't the same. You need to read a lot more about CSS, DOM, HTML etc.