As discussed on IRC, there are 3 ways to think:
There might be some more and we gotta choose one.
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 ? ;-]] )
Well, besides the million and one we couldn't focus yet there is the following that we have been able to see:
That problem descibed above being the only fondamental one our eyes have seen the rest should be architectured around it. That would mean that once we get the DOM tree we would do as following: determine the overlapments: "separate" these parts by putting them into different BBitmap and finally make all these BBitmaps being rendered at the correct place in the browser's view.
Yeah, improving a silly idea is another silly one but hey, aren't we doing a browser or what ?
Let's get it straight: My view is to make up each BBitmap into a seperated thread. That should permit a fast rendering (we can even play with priorities to boost certain ones under certain conditions (like: contains a flash animation !)). One other good point out of that mess is: let's say the Browser's view get an Invalidate(BRect[a,b,c,d]) call. Instead of stopping all the process of building the UI Tree we would just have to stop the thread(s) in charge of that BRect. That would mean that while some render, other process. Moreover, once a part of the screen is drawn into a BBitmap and if there is no animation: all we have to do is to draw that Bitmap which is quiet just a mem_copy() without any drawing calls !
Some say, "A brain is like a parachute, if you don't have one when needed you crash."
| cons | is surely the most complex way to implement |
| must have specific ways to perform certain actions (like select text) | |
| high administration usage | |
| pros | can render the doc part by part as data come in |
| double-buffering |
The idea here is to kick overlapments at their sources by saying that whatever what happens, only one BView handle a message. So all we have to do is the system to get the correct BView despite overlapments. I think it's not pretty hard: all we have to do is I think the following:
The parent BWindow keeps a BList/linked list or whatever of BRegions which are in fact the BRect of the BViews to which are attached a "level". This level is a simple int32 that describes the level of attachment of the BView. For instance the BView directly attached to the BWindow has level 1. A view attached to this BView has level 2, etc...
So, when we mouse click for instance, the view that will have to handle the message will be the one which contains the BPoint of the click + with the greatest level.
This system would be easy has we wouldn't have to really care about overlapments, building our UI tree like anyone would do.
So, when an incoming message arrive, a BMessageFilter attached to the Renderer BView determines the correct BHandler with the BRegions and passes the message to it.
| cons | eats more memory |
| pros | simple |
| keeps Parser and Renderer independents (if it's really a pro) |
The idea araise from the fact that the DOM tree and a BeOS UI tree look very similar in term of structure: You addChild objects doing thehierarchy for instance. Some have specific functions but all derives from the same thing (TNode/BView at first glance), etc...
So the idea is to merge the UI tree building and the DOM tree. Here all we would have to take care of is to keep the DOM specifications and standarts while we plug the BeOS specific things. All in all, all we need is a good design but as a result what we would get is probably <mode_troll>the fastest browser on this planet.</mode_troll>
Here is an exemple which displays an intermediate way (meaning that the Parser builds up only part of the BeOS UI):
We can say that HTML tags or JS or whatever have two kinds of effects: build up specific objects (like BTextControl, BButton, BView,etc...) or make those objects behave particularly (Font in Bold, Italic, Animated GIF, etc...). The parser could build just the tree of Objetcs and some other process (well, could be name the "half-renderer" would set those ojects behaviour.)
I take an exemple: In the classical way, when the HTML parser mets a TAG that looks like <input type=radio name="name"> it builds up a TNode with specifics Attributes and then when the renderer get to that TNode, it builds up the BButton reading the attributes. What I'm trying to say is: Why not just build up directly the BButton ? (in the "complete" way the parser would build up the object and determine it's behaviour.) The reason is that if we do some, looking at all the possible TAGs and all we may loose the compatibility to the DOM specifications. Indeed the DOM Tree would become a pure BeOS UI tree and so some specific things about it might be lost. That problem (I think) could be solved by merging the two trees: Imagine a class inheriting from TNode and BButton: instead of storing the TAG as Attribute, it will directly store it as the object itself contains that data. Now, the DOM specific things could still be kept as attributes and be red later.
Another great thing is the similarity of structure between the DOM tree and the UI tree. Indeed if you look at the TNode class you will see that many methods are common:
GetParentNode()/GetFirstChild()/GetLastChild()/AppendChild()/InsertBefore(), etc...
and you will note that most of these functions concern the structure of the tree and not the data itself mening that if we have "merged class of TNode and BButton" (in fact TNode & BView) we could replace all the TNode versions to only use BeOS ones !
Here Implementation = Design++;
We will have to define the "++" operator thought. ;-]
| cons | Design will be the thing to not miss |
| pros | Will be really fast: indeed, no need to build the read the Node tree, almost only build it would be enough |
| is cheaper in memory than the others: BeOS vars and DOM ones could be partially merged. | |
| Simle as te "Classical" way once Design is done. |
So let's debate about what's above shall we ? ;-) (In fact what I'd like is the binary answer: continue with that track or stop and start again smashing my head against the walls.)
Thx 4 reading,
Olivier MILLA