Minutes Hackathon 2012 03 27

Here are some notes from our Hackathon on 2012-03-07.

• What kind of data structure do we use?
• RCU
  • clean/dirty, has a rd/wr ptr
  • when making dirty, copy over and adjust wr ptr
  • keep a linked list of dirty nodes
  • when you join layout, walk over and reset reader ptrs
  • However:
    • Refresh driver, particularly around animations, can async trigger layout
    • What do we do when JS is running and the timer goes off?
      • is it enough to just set the 'layout is running' flag?
      • have to be sure that it's always safe at any time
      • Danger points:
        • about to join
        • JS is about to write:
          • it needs to know if it can make a copy
        • much simpler:
          • make use of the operation callback to stop JS
          • operation callback every .5ms to 1ms seems sufficient
        • an alternative:
          • on every dom mutation grab a spin lock
          • try to get smart with compare-and-swap? but that's just a spin lock
• How many pipeline stages for the layout?
  • Clear stages:
    • Computing styles
    • Create Layout
    • Layout Layout
    • Create paint
    • Paint (rasterize / composite)
  • When we want to join the layout, what do we need:
    • sometimes the DOM wants style information, but not layout
    • we probably want to have
  • In general, layout is probably two stage:
    • computing class information
    • computing geometry
    • sometimes we just join the class info
    • sometimes we tell layout to stop after class info
• create paint:
  • needs to run in "the layout task"
  • display list
    • contains display items: things that paint themselves
  • once we have the display list, do we still need the DOM?
    • bz says ... "mostly done with the DOM"
    • do need DOM to some extent during DL construction because you have to sort things by Z order
    • One "obvious" exception
      • Canvas: it has a bitmap backing store
        • we'll probably need a double buffered setup
      • today: HW accelerated canvas could cause issues
        • WebGL'd canvas
      • connection between canvas and paint is the backing store
    • right now we do not persist the display items
      • but we do the layer tree
      • these are cases where rasterization is expensive
      • we think this can be handled locally by a (theoretical) paint task
• Parallelizing layout
  • Floats: contaminate up to the block formatting context (BFC)
  • Layout: multi-step process
    • first, compute intrinsic widths
    • CSS layout:
      • width is input, height is output
      • for a typical block, you determine its width, then layout kids to determine height
        • computing width:
          • look at style, border, margins, etc
          • some things do "shrink-wrapping", where width depends on children
          • for floats with autowidth-
            • find intrinsic / preferred minimum width
            • find max of longest word and (min of avail and preferred)
            • computing intrinsic, preferred width is completely parallelizable
              • does not depend on layout, parent
            • same applies to table cells
            • so even within these painful things there are emb. par. portions
          • what about floats with fixed width---
            • still don't know height, but things are somewhat easier
    • is the CSS layout truly so complex?
      • another question: flexibility
        • highly tuned, manually written code is very inflexible
        • automatically generated, highly tuned code is fast but of medium flexibility
        • simple, hand-written code may be slow but very flexible
• DOM.js
  • we should move to an IDL-based autogeneration mechanism like in Gecko
  • something we need---
    • fast way to validate type of arguments, not necc. easy in JS
  • should be able to repurpose the front end (Python program that generates a data structure)
  • should be able to tweak and repurpose the code gen to produce code
    • to some extent it's properly setup