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 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 working but it didn't work properly although in theory it is all there.