diff options
authorMichael Drake <>2019-05-03 10:03:01 +0100
committerMichael Drake <>2019-05-03 10:03:01 +0100
commit541a1b75d2ff8e61aa79608f20c7d9d1e17cc4c2 (patch)
parentf38e29beb4132e3597b58177e16b0831e203365a (diff)
Add dev weekend page.
1 files changed, 101 insertions, 0 deletions
diff --git a/developer-weekend/may-2019.mdwn b/developer-weekend/may-2019.mdwn
new file mode 100644
index 0000000..e32b2cf
--- /dev/null
+++ b/developer-weekend/may-2019.mdwn
@@ -0,0 +1,101 @@
+[[!meta title="Developer Weekend (May 2019)"]]
+[[!meta author="NetSurf Developers"]]
+[[!meta date="2019-05-03 10:00:00"]]
+* Michael Drake
+* Vincent Sanders
+* Daniel Silverstone
+* 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
+* 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.
+* Looked into how we could hack dynamic layout into the
+ current layout engine, and wrote it up (above).