Khaos: WPF Web Browser

Updated Wiki: Home

Lavinski — Tue, 02 Mar 2010 22:26:08 GMT

Khaos Web Browser

This project is the development of a web browser in C#

The browser is still in early stages of development and only supports basic static webpages.

The Khaos project goals are to build a browser that is easy to understand and extend. This is done by placing focus on high quality design and architecture the result is a highly extensible and modular series of web technology components. Emphasis is also placed on simplicity and code quality in order to enhance understanding and extensibility.

Screenshot of the current version

You can follow my personal blog at http://lavinski.wordpress.com

Thanks from EXtreme Solutions @ http://www.extremesolutions.co.nr.

Updated Wiki: Home

Lavinski — Tue, 02 Mar 2010 22:25:34 GMT

Khaos Web Browser

Updated Wiki: Documentation

Lavinski — Thu, 22 Oct 2009 12:17:46 GMT

Visual Model
The visual model is responsible for determining the visual representation of the content using the document object model and cascading sheet style information. The visual model determines the measurements and arrangement of all the document nodes as well as defining the appearance for each fundamental node type.

Our implementation of the visual model is build on top of the Windows Presentation Foundation (WPF) framework. The framework supports event notification for inputs and pixel perfect mouse hit testing. This has allowed us to use framework functionality to focus on the layout and rendering. The layout system for WPF is two phase, the first phase calculates the measurements for each visual node then the second phase arranges the nodes. Visual nodes maintain a visual tree and a logical tree representation. The logical Tree is used for the notifications such as input and other events as well as resource management. The visual tree describes the structure of visual objects, as represented by the Visual base class. As a side effect however any node can only be the child of at most one other node and a strict child parent relationship must be maintained.
An alternative to using the WPF framework would have been to use the WPF for GDI+ drawing API’s. These API’s provide basic drawing capabilities which allow the drawing of objects such as shapes, lines, images or text. For the development of a rendering engine using this API it is up to the developer to encapsulate the API with a higher level framework that allows HTML rendering. We ended up choosing to use the WPF framework for our visual model base. By using the WPF framework it makes this process much easier and allows for a more powerful solution. It also allows better integration into Windows Presentation Framework applications.

The construction of the visual model takes place after the creation of the Document Object Model. This process is initiated in the web engine, which allows supplies the request used and an IPageHost implementer. The transformation is processed by the TransformManager which handles a set of supported transformations. Each Transformation is an implementation of the ITransformable interface. This interface provides methods to check supported tags and to perform and transformation from IHTMLElements to a VisualNode or superclass. The transformation builds up the new hieratical model using an iterative stack based approach.

The visual model makes use of a number of data structures. The child manager maintains the link between a node and its children as well as the nodes parent. The split manager maintains the information about where splits were created.
The visual model structure is initialised only once when the DOM is first transformed. Resetting and recalculation are performed whenever the constraint measurements like window size are changed. Refreshing the Visual Model resets the tree by removing all node splits therefore reverting the tree to its original state. We chose not to just rebuild the tree which may have been slightly simpler because rebuilding the tree in WPF was too expensive.

The recursive VisualNode measurement algorithm is the main section of the visual nodes. The algorithm determines the largest possible size a visual can take up using the constrain information passed down to it. The final largest possible size is the maximum of the constraint largest size and the largest child size. Node Children are then measured and their desired sizes are used to calculate the final desired size of the current node. The algorithm supports the two main display types, block and inline which determine how sizes are calculated. Nodes with block layout are simply measured and added to a new line after which a newline is forced. Inline nodes however are much more complicated because they have the potential to be split over multiple lines. To find the number of inline elements that can be placed on a line before splitting each child is asked if any part of it is able to fit into the width left on the line. When a child is found that cannot fit the remaining children are split off into a new visual node. Split visual nodes do not own their own split and child managers but instead share the managers of the original node. Children that only fit after a split is made are not a case that needs to be handled here because the child well automatically split to take up the most space on a line.

Overall the visual tree that we use is able to correctly manage the visual components and provides a solution that we are happy with. The method provides a more efficient and powerful solution then would have been otherwise possible considering time constraints.

Visual Model Supports:

*Display
Block
Inline
*Types
Generic Elements
Images
Input (text and submit)
Text
Tables
NoScript
NoFrame
Labels
Centering
Line Breaks
Anchors/Links

Updated Wiki: Documentation

Lavinski — Thu, 22 Oct 2009 12:14:09 GMT

Visual Model
The visual model is responsible for determining the visual representation of the content using the document object model and cascading sheet style information. The visual model determines the measurements and arrangement of all the document nodes as well as defining the appearance for each fundamental node type.
Our implementation of the visual model is build on top of the Windows Presentation Foundation (WPF) framework. The framework supports event notification for inputs and pixel perfect mouse hit testing. This has allowed us to use framework functionality to focus on the layout and rendering. The layout system for WPF is two phase, the first phase calculates the measurements for each visual node then the second phase arranges the nodes. Visual nodes maintain a visual tree and a logical tree representation. The logical Tree is used for the notifications such as input and other events as well as resource management. The visual tree describes the structure of visual objects, as represented by the Visual base class. As a side effect however any node can only be the child of at most one other node and a strict child parent relationship must be maintained.
An alternative to using the WPF framework would have been to use the WPF for GDI+ drawing API’s. These API’s provide basic drawing capabilities which allow the drawing of objects such as shapes, lines, images or text. For the development of a rendering engine using this API it is up to the developer to encapsulate the API with a higher level framework that allows HTML rendering. We ended up choosing to use the WPF framework for our visual model base. By using the WPF framework it makes this process much easier and allows for a more powerful solution. It also allows better integration into Windows Presentation Framework applications.
The construction of the visual model takes place after the creation of the Document Object Model. This process is initiated in the web engine, which allows supplies the request used and an IPageHost implementer. The transformation is processed by the TransformManager which handles a set of supported transformations. Each Transformation is an implementation of the ITransformable interface. This interface provides methods to check supported tags and to perform and transformation from IHTMLElements to a VisualNode or superclass. The transformation builds up the new hieratical model using an iterative stack based approach.
The visual model makes use of a number of data structures. The child manager maintains the link between a node and its children as well as the nodes parent. The split manager maintains the information about where splits were created.
The visual model structure is initialised only once when the DOM is first transformed. Resetting and recalculation are performed whenever the constraint measurements like window size are changed. Refreshing the Visual Model resets the tree by removing all node splits therefore reverting the tree to its original state. We chose not to just rebuild the tree which may have been slightly simpler because rebuilding the tree in WPF was too expensive.
The recursive VisualNode measurement algorithm is the main section of the visual nodes. The algorithm determines the largest possible size a visual can take up using the constrain information passed down to it. The final largest possible size is the maximum of the constraint largest size and the largest child size. Node Children are then measured and their desired sizes are used to calculate the final desired size of the current node. The algorithm supports the two main display types, block and inline which determine how sizes are calculated. Nodes with block layout are simply measured and added to a new line after which a newline is forced. Inline nodes however are much more complicated because they have the potential to be split over multiple lines. To find the number of inline elements that can be placed on a line before splitting each child is asked if any part of it is able to fit into the width left on the line. When a child is found that cannot fit the remaining children are split off into a new visual node. Split visual nodes do not own their own split and child managers but instead share the managers of the original node. Children that only fit after a split is made are not a case that needs to be handled here because the child well automatically split to take up the most space on a line.
Overall the visual tree that we use is able to correctly manage the visual components and provides a solution that we are happy with. The method provides a more efficient and powerful solution then would have been otherwise possible considering time constraints.
Visual Model Supports:

o Display
 Block
 Inline
o Types
 Generic Elements
 Images
 Input (text and submit)
 Text
 Tables
 NoScript
 NoFrame
 Labels
 Centering
 Line Breaks
 Anchors/Links

New Post: Your Comments

lavinski — Sat, 18 Jul 2009 01:31:23 GMT

Hey, could you leave any comments about the project here. Thanks

Updated Wiki: Home

Lavinski — Thu, 28 May 2009 05:47:20 GMT

Khaos Web Browser

This project is the development of a web browser in C#

The browser is still in early stages of development and only supports basic static webpages.

The Khaos project goals are to build a browser that is easy to understand and extend. This is done by placing focus on high quality design and architecture the result is a highly extensible and modular series of web technology components. Emphasis is also placed on simplicity and code quality in order to enhance understanding and extensibility.

Screenshot of the current version

Thanks from EXtreme Solutions @ http://www.extremesolutions.co.nr.

Updated Wiki: Home

Lavinski — Thu, 28 May 2009 05:39:32 GMT

Khaos Web Browser

This project is the development of a web browser in C#

The browser is still in early stages of development and only supports basic static webpages.

Screenshot of the current version

Thanks from EXtreme Solutions @ http://www.extremesolutions.co.nr.

Updated Wiki: Home

Lavinski — Thu, 28 May 2009 05:00:57 GMT

Khaos Web Browser

This project is the development of a web browser in C#

Thanks.

Updated Release: Project Prototype (May 27, 2009)

Lavinski — Thu, 28 May 2009 04:41:10 GMT

First version release prototype

Released: Project Prototype (May 27, 2009)

Thu, 28 May 2009 04:41:10 GMT

First version release prototype

Created Release: Project Prototype (May 27, 2009)

Lavinski — Thu, 28 May 2009 04:29:45 GMT

First version release prototype