summaryrefslogtreecommitdiff
path: root/developer-weekend/may-2019.mdwn
blob: e32b2cf6b4d466813d36b41c404d2d482f83edb7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
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
-----