The text-engine rendering model is a very simplified version of most major browsers:
It consists of five individual trees:
Model: A hierarchical description of the document (basically HTML with fewer elements)
Format: A cascade of styles (CSS circa v2?)
Style: Matching model elements with their relevant styles to construct an efficient representation of the fully formatted document
Layout: Recursively determines how large elements want to be, what size they should be (in relation to the available space), etc. The layout module is designed to be hotswappable by the end user, so they can customise text-engine to their liking (the other models are likely to be internal only). Different layouts can be used to achieve things like reflowable vs paged layouts.
Display: Convert layout nodes to platform specific drawing commands. Also responsible for things like occlusion culling, etc. GTK code may exist ONLY in this stage. This would also let us support e.g. Qt, GTK3 if someone shows up with patches.
Each tree is cached and only updates relevant parts whenever a previous tree is invalidated (see #11). Style nodes and layout nodes will be attached together; there is a one-to-one relationship between them. Style nodes wrap model nodes and index format nodes. I might simplify this by dropping style altogether and make model nodes refer to format directly.
The text-engine rendering model is a very simplified version of most major browsers:
It consists of five individual trees:
Each tree is cached and only updates relevant parts whenever a previous tree is invalidated (see #11). Style nodes and layout nodes will be attached together; there is a one-to-one relationship between them. Style nodes wrap model nodes and index format nodes. I might simplify this by dropping style altogether and make model nodes refer to format directly.
Once implemented, it should be fully documented.