diff options
| -rw-r--r-- | developer-weekend/may-2019.mdwn | 101 |
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"]] + +[[!toc]] + +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 +----- + + |