Themis - Renderer Design v 0,0000000002

The old design doc can be found here .

Summary:

I-What's the job ?

The renderer takes out the work of the HTML/CSS Parsers which is a tree of TNodes (a DOM Tree) and generate UI/Drawing instructions to "put stuff on screen" (what ? You can't browse the web with just the DOM Viewer ? ;-]] )

II-What's the problem with the old Deisng doc ?

Well, our international Yak and mahlzeit have enlightened us during a long chat (the log is here (no link by now)) which made quiet obvious the sillyness of :

  1. Trying to render things into BBitmaps for double-buffering and make a complicated use of them (like mapping it, manage the UI Tree on our own, etc...). Moreover, double buffering is managed by Dano's app_server and so Zeta's one and will for sure be implemented internally in OpenBeOS app_server.
  2. Consider views overlapments problem . According to DeadYak, there should be no overlapment that cannot be managed by BVIew::SetViewBitmap() or B_OP_ALPHA drawing option into HTML code.

III-So, what's new ?

Building the tree with pure BeOS UI stuffs and behaviour is the simplest of all way. Nevertheless, it doesn't provide some needed behaviours fundamentals to a WebBrowser: Multiple selecting of text for instance (indeed, the selected text can be spread onto different BViews...)

Therefore, what I think we have to do is a Special Controler of some user events that BeOS has no way to manage by it's direct API and which aren't just "rendering stuffs". This "layer" -managing the concerned events- would fit at the top of the UI hierarchy. As it's role is mainly maintainership of some interface states and internal states which are both particular and might need quiet some CPU I propose to make it run into it's own Thread.

What we should now do is build up the list of things that BeOS cannot directly accomplish like said above and which should be therefore managed by the "layer" before we find a way to implement each of these controls. ( /me hides)

Here is a start:

Beside this layer, the UI will be then only the construction of a BeOS UI stuffs and it's behaviour.

IV-Some speed-up...maybe.

Back to the old document, there's been the idea of the "DOM+UI Tree" way which was to make the HTML/CSS Parser do some pre-processing and pre-constructing of UI objects to speed up the page rendering and the memory use. Regarding the precedent pargraph, doing such a way is next to impossible. But, as proposed our Boss (Raymond, I see you !) there is a lightest version of "DOM+UI Tree" which could still be applied with some results. It is that the Parser calaculates the coordinates (at least the originals, regarding that a resizing change the whole thing) of the UI objects directly and put them in BeOS datas eventually: BPath/BRect/BPoint/BList, etc...