Re: Why Emacs should have a good web-browser

[Thomas Lord <lord@emf.net>]

On Wed, 2009-07-22 at 01:31 +0900, Miles Bader wrote:

> I don't know how well these engines deal with the underlying text
> changing; given that a small text change might affect the _entire_
> "rendered" data structure, there seems a good chance the answer might be
> "not very well."
> 
> But all of this is mostly speculation on my part...


A modern browser rendering engine presents (e.g.
to Javascript programs) a "DOM" (data object model)
interface to the contents of a page.   The DOM
is a tree structure that functions as a hierarchical
display list and window system windows are automatically
updated from that display list and from changes made
to it.   All of the mechanism of CSS is available to 
control the rendering of that display list.

The natural way to use this for an Emacs display
is *not* to try to store all of a buffer's text 
in the DOM but rather to use the DOM for only the 
visible content of an Emacs frame.   For example,
the scrollbars on a typical browser window would not
be used here:  Emacs would have to implement its own
style of scrollbars as DOM elements.

In terms of performance:  modern browser rendering
kits are fast enough -- although probably only "barely"
so.  They'll get better (through code improvement,
not faster hardware).     People have been building
GUI toolkits that use the DOM as their display engine
for several years now and each year the results 
become more and more impressive.

(A question nagging me, lately:  how good would
the performance be of an implementation of Elisp
in Javascript....  The result would be a second
implementation of GNU Emacs, not a replacement for
the GNU Emacs we have.).

-t