| 13 | | * There are render objects and a render tree |
| 14 | | * There is also a line box tree that does text handling and line - we're largely going to ignore this |
| 15 | | * Everything with "inline" in the name |
| 16 | | * There is also RenderLayer, which can mostly be ignored unless you're doing compositing or other more advanced things |
| 17 | | |
| 18 | | The RenderTree is kind of like a scene list/graph or a display list - it's a fast way of figuring out what to draw rather than having to go back to the DOM |
| | 13 | * There are render objects and a render tree |
| | 14 | * There is also a line box tree that does text handling and line - we're largely going to ignore this |
| | 15 | * Everything with "inline" in the name |
| | 16 | * There is also RenderLayer, which can mostly be ignored unless you're doing compositing or other more advanced things |
| | 17 | *The RenderTree is kind of like a scene list/graph or a display list - it's a fast way of figuring out what to draw rather than having to go back to the DOM |
| 22 | | * RenderObject |
| 23 | | * RenderText - holds text and keeps a line box tree. Some things need different styling and become subclasses, e.g. |
| 24 | | * RenderCombineText, RenderTextFragment, etc. |
| 25 | | * RenderBoxModelObject - where most new elements come in for elements in the CSS box model (there are either inline or boxes in the CSS box model) |
| 26 | | * RenderBlock - if you have text children that need to flow or if you need to be a containing block |
| 27 | | * RenderInline - for SPAN, etc. ... are rendered by their containing block |
| 28 | | |
| 29 | | * What do you subclass from? |
| 30 | | * RenderBlock - if you have children |
| 31 | | * RenderFixed - if you are a single element with a fixed size |
| 32 | | * RenderObject - if you need to do something unusual |
| 33 | | |
| 34 | | * What do you need to implement? |
| 35 | | * layout() |
| 36 | | * paint() |
| | 21 | * RenderObject |
| | 22 | * RenderText - holds text and keeps a line box tree. Some things need different styling and become subclasses, e.g. |
| | 23 | * RenderCombineText, RenderTextFragment, etc. |
| | 24 | * RenderBoxModelObject - where most new elements come in for elements in the CSS box model (there are either inline or boxes in the CSS box model) |
| | 25 | * RenderBlock - if you have text children that need to flow or if you need to be a containing block |
| | 26 | * RenderInline - for SPAN, etc. ... are rendered by their containing block |
| | 27 | * What do you subclass from? |
| | 28 | * RenderBlock - if you have children |
| | 29 | * RenderFixed - if you are a single element with a fixed size |
| | 30 | * RenderObject - if you need to do something unusual |
| | 31 | * What do you need to implement? |
| | 32 | * layout() |
| | 33 | * paint() |
| 42 | | * transforms? |
| 43 | | |
| 44 | | * RenderText vs inline text boxes? |
| 45 | | |
| 46 | | * xpos / ypos ? have been replaced by accumulated offsets - how do these relate to absolute positioning? |
| 47 | | |
| 48 | | * logical vs. physical coordinate spaces (e.g., RTL - does x mean "from left" or "from start")? |
| 49 | | |
| 50 | | * painting the line box tree |
| | 39 | * transforms? |
| | 40 | * RenderText vs inline text boxes? |
| | 41 | * xpos / ypos ? have been replaced by accumulated offsets - how do these relate to absolute positioning? |
| | 42 | * logical vs. physical coordinate spaces (e.g., RTL - does x mean "from left" or "from start")? |
| | 43 | * painting the line box tree |
| 54 | | * done in two separate parts of the tree, one for html/css, one for svg |
| 55 | | |
| 56 | | * for html/css, done in RenderLayer - the layer handles transforms, masking, clipping, etc. RenderObjects are supposed to be dumb. |
| 57 | | |
| 58 | | * in svg, all of the objects know how to handle transforms intrinsically |
| | 47 | * done in two separate parts of the tree, one for html/css, one for svg |
| | 48 | * for html/css, done in RenderLayer - the layer handles transforms, masking, clipping, etc. RenderObjects are supposed to be dumb. |
| | 49 | * in svg, all of the objects know how to handle transforms intrinsically |
| 62 | | * parts of the render tree are dumb and just contain data (e.g., text nodes) - these don't layout or paint themselves. In this case the containing object creates a list of lines of text (the line box tree) and the containing object may have to deal with RTL direction, ligatures, etc. |
| 63 | | |
| 64 | | * A RenderTextFragment splits off the first letter to handle "first-letter" |
| 65 | | |
| 66 | | |
| | 53 | * parts of the render tree are dumb and just contain data (e.g., text nodes) - these don't layout or paint themselves. |
| | 54 | * In this case the containing object creates a list of lines of text (the line box tree) |
| | 55 | * the containing object may have to deal with RTL direction, ligatures, etc. |
| | 56 | * A RenderTextFragment splits off the first letter to handle "first-letter" |
| | 57 | * "first-line" is split off into a different InlineText box |
| 75 | | |
| 76 | | |
| 77 | | |
| 78 | | |
| 79 | | |
| 80 | | |
| 81 | | |
| | 66 | * There are multiple coordinate systems in the rendering tree |
| | 67 | * One is for vertical vs. horizontal writing direction (logical height vs. height) |
| | 68 | * logical vs. document order for RTL (right-to-left text) |
| | 69 | * there might be a third (?) |
| | 70 | * before/after and start/end are CSS concepts that map onto logical and physical in WebKit |
| | 71 | * cf. CSS 3 Writing Modes spec ? |
| | 72 | * always use the logical height and width in order to do the right thing |
| 85 | | * All the painting logic is in RenderBlock, first line down, left to right |
| 86 | | * Creates text run objects and sends those to the GraphicsContext |
| 87 | | * the text run splits between simple and complex |
| 88 | | * the chunking logic is done through the Unicode abstraction to ICU on most ports |
| 89 | | * the logic may also be platform-specific because different text rendering engines may be able to handle different things (e.g., ATSUI vs. DirectWrite) |
| 90 | | * the LTR/RTL logic sorts a list of text runs |
| 91 | | * How do we figure out when to break for lines? |
| 92 | | * all in RenderBlockLineLayout - calls out to ICU to figure out where breaks can occur |
| 93 | | * then we measure the widths of the glyphs and determine where we might want to break |
| 94 | | * There is also a cache of glyphs so that we can measure each character quickly |
| 95 | | * Unclear how this interacts with complex text runs |
| 96 | | * also text rendering optimize legibility can through you down the complex text path |
| 97 | | * |
| | 76 | * All the painting logic is in RenderBlock, first line down, left to right |
| | 77 | * Creates text run objects and sends those to the GraphicsContext |
| | 78 | * the text run splits between simple and complex |
| | 79 | * the chunking logic is done through the Unicode abstraction to ICU on most ports |
| | 80 | * the logic may also be platform-specific because different text rendering engines may be able to handle different things (e.g., ATSUI vs. DirectWrite) |
| | 81 | * the LTR/RTL logic sorts a list of text runs |
| | 82 | * How do we figure out when to break for lines? |
| | 83 | * all in RenderBlockLineLayout - calls out to ICU to figure out where breaks can occur |
| | 84 | * then we measure the widths of the glyphs and determine where we might want to break |
| | 85 | * There is also a cache of glyphs so that we can measure each character quickly |
| | 86 | * Unclear how this interacts with complex text runs |
| | 87 | * also text rendering optimize legibility can through you down the complex text path |
| 101 | | |
| 102 | | |
| 103 | | |
| 104 | | |
| 105 | | |
| 106 | | |
| 107 | | |
| | 91 | * everything in the render tree is single ownership (new/delete), not ref counted |
| | 92 | * per-document memory arenas for quick destruction |
| | 93 | * there is a single renderer per document rooted at the RenderView |
| | 94 | * display:none objects have no render objects |
| | 95 | * each renderer has 0 or 1 pointers to Nodes; renderers with 0 pointers are "anonymous" |
| | 96 | * you can see the render tree in safari after enabling the internal debug menu and turning off Webkit 2 |
| | 97 | * and of course in the -expected.txt files in the LayoutTests |
