Miscellaneous notes from Jon Ribbens, the original author.
        ----------------------------------------------------------

It is hoped that these notes may provide someone with a few clues as to
how they could go about fixing some of the bugs in the browser.  N.B. These
notes were compiled by Richard Walker, from email messages from Jon.


General workings of the browser
-------------------------------

Hmm. Well, the basic idea is that it is all a co-routine, i.e. it is
written as if it was a single thread, it just calls BL poll or somesuch
every so often in order to let other processes have a turn. This is fun
because all the code, and the stack, is in WimpExt Heap blocks which
can move when you call 'poll'. But that's basically all taken care of
by the poll routine, which makes sure everything's okay again when it
returns.

The entry point is html_to_draw, if I remember right, and that's almost
exactly what it does. It converts the HTML into a draw file, held in
one contiguous block in memory (which is why it can sometimes say 'out of
memory' when it shouldn't be really, due to heap fragmentation and
WimpExt's block extension rules). It's really because when I started writing
it, the web was a totally different thing than it is today, and it was
slightly more reasonable to do it this way then.

The code goes through building up characters into a buffer until it has
to change style or it reaches the end of a paragraph or something like that,
then it dumps them all out to the draw file. The draw file is built up line
by line, and when a line is complete it calls fragline or somesuch in order
to shuffle all the objects around to line them up correctly and take account
of <img align=middle> and suchlike. Until they are fragged the objects often
have made-up draw object ids. There is a pointer 'safeend' or something
which tells the renderer what is the last point in the draw file it is
currently safe to render to.


'Out of memory during HTML to Drawfile conversion'
--------------------------------------------------

I think this is because of the original spec of WimpExt's heap blocks - that
they will not move except on calls to the compact routines. If you try to
extend a block (and remember that Webite's output draw file must reside all
in one block) and it is not the highest one in memory then you need enough
memory for the original block plus the new total size. Then imagine that
this can happen many times in a row while html_to_draw is running...

This is why a lot of the heap alloc calls in html_to_draw have been modified
to call Wimp_Poll (and hence the heap compact routines) if they fail and
then try again.

The easiest way to fix this, I suspect, would be to make the output data
a linked list of draw file chunks.


'Recent' developments
---------------------

There is stuff there to do 'margin objects' which was to try and get
<img align=left|right> working but it didn't work properly although in
theory it is all there.