blob: 3107d165de94c6a40549316606c9f5a9f63fe393 (
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
102
103
104
105
|
[[!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
-----
Next time
=========
1st August to 6th August, Manchester.
|
