Changes between Version 4 and Version 5 of April 2012 Write Your Own Render Object


Ignore:
Timestamp:
Apr 20, 2012 2:41:24 PM (9 years ago)
Author:
dpranke@chromium.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • April 2012 Write Your Own Render Object

    v4 v5  
    33Eric Siedel
    44
    5 Dirk Pranke, scribe
     5(Dirk Pranke, scribe)
    66
    7 * Goal: give you some comfort if you have to write a rendering patch next week
    8 * Give you some idea about how to create a new object
     7  * Goal: give you some comfort if you have to write a rendering patch next week
     8  * Give you some idea about how to create a new object
    99
    10 * There is an intro talk on Youtube from Eric from a few years ago on this ...
    11 * There is a page linking to Hyatt's blog posts
     10  * There is an intro talk on Youtube from Eric from a few years ago on this ...
     11  * There is a page linking to Hyatt's blog posts
    1212
    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
    1918
    2019== Class hierarchy ==
    2120
    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()
    3734
    3835First figure out how big you are : figure out your width. then size your kids, and then compute your height as necessary to fit everything
     
    4037== Pause for Questions - what do people want to know about? ==
    4138
    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
    5144
    5245== Transforms ==
    5346
    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
    5950
    6051== RenderText vs. InlineTextBox ==
    6152
    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 * "first-line" is split off into a different InlineText box
     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
    6758
    6859== X-Position and the absolute coordinates ==
    6960
    70 * most objects maintain coordinates from their containing block - you can get the absolute coordinates by either walking up the dom tree computing offsets or going to the RenderLayer which maintains a cache.
    71 * when you are "position: absolute" you have to go to your positioning context and ancestor instead
     61  * most objects maintain coordinates from their containing block - you can get the absolute coordinates by either walking up the dom tree computing offsets or going to the RenderLayer which maintains a cache.
     62  * when you are "position: absolute" you have to go to your positioning context and ancestor instead
    7263
    7364== Logical vs. Physical coordinate spaces ==
    7465
    75 * There are multiple coordinate systems in the rendering tree
    76   * One is for vertical vs. horizontal writing direction (logical height vs. height)
    77   * logical vs. document order for RTL (right-to-left text)
    78   * there might be a third (?)
    79   * before/after and start/end are CSS concepts that map onto logical and physical in WebKit
    80     * cf. CSS 3 Writing Modes spec ?
    81     * always use the logical height and width in order to do the right thing
     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
    8273
    8374== How the Linbox Tree Paints ==
    8475
    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
    9888
    9989== Implementation Notes ==
    10090
    101 * everything in the render tree is single ownership (new/delete), not ref counted
    102 * per-document memory arenas for quick destruction
    103 * there is a single renderer per document rooted at the RenderView
    104 * display:none objects have no render objects
    105 * each renderer has 0 or 1 pointers to Nodes; renderers with 0 pointers are "anonymous"
    106 * you can see the render tree in safari after enabling the internal debug menu and turning off Webkit 2
    107 * and of course in the -expected.txt files in the LayoutTests
     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
    10898
     99== Questions ==
    109100
    110 
     101  * Should everything be deriving from RenderBlock? That does a lot ...
     102    * Yes, although there is discussion of breaking up the RenderBlock object
     103 
     104  * Should we blur the lines between nodes and renderers so that nodes could have multiple renderers (e.g., for pull quotes in regions, or for shadow dom?)
     105    * Possibly we can do enough of this with anonymous render blocks
     106    * e.g., -moz-element
     107    * SVG does this to some extent already becaues of the way the SVG dom works?
     108    * this is similar to how regions work
     109     
    111110