-
Notifications
You must be signed in to change notification settings - Fork 28
may 2019
!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
- 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)
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.
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
DOMSubtreeModifiedevents 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
DOMSubtreeModifiedevents 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.
We did a basic triage and catagorized all outstanding 'new' issues
- Looked into how we could hack dynamic layout into the current layout engine, and wrote it up (above).
- merged media queries
- lots of javascript fixes
- assist with media queries merge
- Fixed nsgenbind output so it correctly places #line directives greatly improving debug output usefulness
- wrote document on creating bindings
- improved monkey tests
- assist with media queries merge
If at all possible, we'd like to see some of the following addressed before the next developer weekend…
- General
- release 3.9 (vince)
- Monkey
- Driver - capability to "Click" on a specified piece of text (Daniel) (Basically a way to say click button FOO)
- Framebuffer
- Language support for resources (Vince)
- Listing of compiled-in surfaces (Vince)
1st August to 6th August, Manchester.