Attendees

  • Michael Drake
  • Vincent Sanders
  • Daniel Silverstone

Apologies

  • John-Mark Bell

Statement of work (from February)

If at all possible, we'd like to see some of the following addressed before the next developer weekend…

  • Monkey
    • Ability to inject an arbitrary piece of JavaScript (Daniel)
    • Driver - capability to "Click" on a specified piece of text (Daniel) (Basically a way to say click button FOO)
  • JavaScript
    • Some documentation around how to write bindings (Vince)
  • Dynamic relayout
    • Write up documentation around whether we can regenerate the box model as a sop to basic dynamic content changes. (Michael)
  • Framebuffer
    • Language support for resources (Vince)
    • Fontconfig (Vince)
    • Listing of compiled-in surfaces (Vince)
  • LibCSS
    • Finish media queries (Michael)

Hacking the current layout engine to do dynamic layout

The idea would be to schedule the creation of a new box tree when we get DOMSubtreeModified events. Then run layout on the new box tree, and pivot to the new box tree and free the old one.

Issues

Unfortunately there are a load of reasons this is not straightforward.

  • Box tree construction is itself restartable and yields between elements. This means that while we are performing the new box tree construction, activity could be happening on the DOM tree causing new DOMSubtreeModified events to occur. One (dodgy) approach would be to cancel any ongoing box tree construction when the DOM is modified.
  • Box tree construction uses talloc, and the html_content is used as the context. So boxes have the lifetime of the html_content. Unless this is changed, memory use would just grow with each new box tree created for the html_content.
  • During box tree construction we rummage around inside the html_content quite a bit. This would all need sanitised.
  • During box tree construction we kick off fetches for things, these affect the html_content's outstanding fetch counter. The content handler for html_content-owned fetches is used to handle a lot of behaviour, such as things like the html_content's throbber, and whether to perform a relayout / redraw.

This would end up affecting a large chunk of the html / box / object / layout code. Even if a large amount were refactored to support this and not break our already creaky lifetimes stuff, the result would be poor because:

  • It would have to do work and and throw it away all the time if it kept getting new DOMSubtreeModified events during box tree reconstructions.
  • It would be really slow because all of the CSS selection work would need redone for each new box tree construction.

Activity

Michael

  • Looked into how we could hack dynamic layout into the current layout engine, and wrote it up (above).

Daniel

Vince