Gitweb links:

...log 
http://git.netsurf-browser.org/netsurf-wiki.git/shortlog/541a1b75d2ff8e61aa79608f20c7d9d1e17cc4c2
...commit 
http://git.netsurf-browser.org/netsurf-wiki.git/commit/541a1b75d2ff8e61aa79608f20c7d9d1e17cc4c2
...tree 
http://git.netsurf-browser.org/netsurf-wiki.git/tree/541a1b75d2ff8e61aa79608f20c7d9d1e17cc4c2

The branch, master has been updated
       via  541a1b75d2ff8e61aa79608f20c7d9d1e17cc4c2 (commit)
      from  f38e29beb4132e3597b58177e16b0831e203365a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commitdiff 
http://git.netsurf-browser.org/netsurf-wiki.git/commit/?id=541a1b75d2ff8e61aa79608f20c7d9d1e17cc4c2
commit 541a1b75d2ff8e61aa79608f20c7d9d1e17cc4c2
Author: Michael Drake <[email protected]>
Commit: Michael Drake <[email protected]>

    Add dev weekend page.

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
+-----
+
+


-----------------------------------------------------------------------

Summary of changes:
 developer-weekend/may-2019.mdwn |  101 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 developer-weekend/may-2019.mdwn

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
+-----
+
+


-- 
NetSurf Developer Wiki Backing Store

_______________________________________________
netsurf-commits mailing list
[email protected]
http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/netsurf-commits-netsurf-browser.org

Reply via email to