Five Year Plan

A collection of thoughts about where we want to take WebKit over the next five years.

DOM Event Loop

High Level:This task would create a DOM event loop construct to be used in WebKit C++ code to provide HTML specification. Lower level: we would use platform run loop representations (ranging from CFRunLoop, to bare threads, to other platform primitives).

• Benefit:
  1. Fix lots of bugs because we enqueue events in one order, but they get fired in some other order.
  2. Would potentially help address our lack of micro-task abstraction.
• Potential problems:
  1. May be difficult to get right.
  2. Need to understand how this will interact with platform run loop

Render Tree Refcounting

Goal is to manage repaint complexity by moving to a refcount model for the Render Tree. The existing tree of nodes with back-pointers is very difficult to reason about.

• Possibly treat render tree as immutable after layout. Use this read-only tree to answer questions about current layout.
• Downside:
  1. Potential for ref cycles.
  2. Slightly larger memory use (additional count)
  3. Potential cost of copying the trees.
• Benefits:
  1. Allow layout and painting logic to be split, perhaps run on separate threads.
  2. Allow us to get rid of some back pointers.
  3. Allow hit testing or other "read only" operations to be done on the read-only tree.
  4. Allow web code to query geometry and other questions without triggering layout.

Painting: Display Lists

Goal is to move drawing off of the main thread. See separate topic.

Image Decoding

We hear from Facebook and others that they want to achieve 60 fps, and find that image decoding is a major bottleneck.

• Perhaps have a heuristic that if an image is large, we eagerly decode?
• Can we break up rendering across multiple frames and allow partially-decoded images to be displayed as retrieved?
• Could sites use progressive JPEGs?
• Would like a way to opt-in to doing the image decoding on a background thread?
• Perhaps a new <img> or <picture> element property:
  1. Causes us to decode on background thread".
  2. Notified when decoding is complete.
  3. Show a placeholder for the image and then trigger.
  4. Major point: Tell WebKit not to block main thread on decoding of this image.
• Might need a way to animate the pop-in of the decoded image to replace the placeholder.
• Many sites do this manually in JavaScript right now. Would be nice to codify these "hacks" in an official way.

Layout State Machine

Need stronger rules (assertions) about when we mark the tree as needing layout, or nodes as needing style recalculation. Want to assert when hit tests or other things are triggered during layout. Tasks would involve the following:

1. FrameView and document updates to make these assertions.
2. Correct the places where our tests cause assertions.

• This task would not be necessary with immutable render trees. This task might be a good step towards that goal.
• We have certain places where layout is done bottom up (e.g., MathML or some tables logic), which is extremely confusing because our normal CSS layout is top-down.
• In general, we should be using assertions to document these kinds of assumptions (or requirements) about the model state during layout or other operations.
• A precondition to this might be to address assertions in existing code; we have some assertions that fire in conditions that are valid.
• We should use asserts with messages.

Compositing

This will be discussed in a separate session.

• Downstream
• Incremental

Hackability

There are some changes we could make to WebKit source code that would make development easier (and safer).

• One large benefit would be the the immutable render tree discussed above.
• Could some complicated high-level code in JavaScript, rather than C++?
• Renaming
  1. RenderRegions rename to Fragment
• Try to find areas that are too complex;
  1. Elimination of continuations in render tree.
  2. Columns with spans
  3. Move line layout out of RenderBlock & RenderBlockFlow
  4. ScrollableArea and FrameView
  5. State of FrameLoader, DocumentLoader, ResourceLoader, ImageLoader, PNGLoader, ThreadSafeCrossOriginLoader, etc. Untenable.
  6. Relationships between Document Frame, DOM Window, and Page.
• Reconcile more of our multi-path code to share more code. We lack some abstractions that would allow the very common code to be shared between the two.\
  1. LineLayout, which has SimpleLineLayout and LineBoxLayout.
  2. Selection, which has iOS and Mac specialized versions.

Threading

Areas that could benefit by being spawned into separate work threads:

1. Text measurement