New Layout: View System

The NGLayout views subsystem is designed to support arbitrary positioning, sizing and depth sorting of overlapping rectangles of content in a platform independent fashion. Most NGLayout rendering operations begin by "damaging" a portion of the area currently being displayed on an output device and then walking over a view tree in z depth order allowing each view to repair parts of the damaged area they occupy. Event handling within NGLayout also goes through the view system giving view objects the first opportunity to handle event processing (within each view, there is generally content represented by layout Frames that do most of the real event processing). View update operations can either happen in an offscreen buffer or directly on the output device depending onthe complexity of the anticipated update. Timed refreshes also occur allowing many damage requests to be processed as a single update to the output device. In addition to representing specially positioned content, a view may also represent an underlying platform native window through it's association with the Widget subsystem. The Widgets can be used to represent application controls such as scrollbars and top level windows and content objects such as HTML form elements. See the Widgets documentation for further information.

Major Components

Currently, there are three different classes within the view system. Naturally, more can be added as deemed necessary:

Basic View class responsible for positioning, sizing, painting and event handling as a container for underlying content.
Scrolling View which has a private child view representing a scrollbar and additional methods for handling the scrolling of one more view that the owner of the scrolling view can add as a child of the scrolling view.
View Manager which coordinates all operations done to/through the view hierarchy including:

child view insertion, removal and sorting.
event handling.
painting.
view state changes (position, size, clip rect, z index, visibility)

Implementation

1. View Manager.

Applications create views and then added them to the view hierarchy through the view manager. From that point on, the application requests that changes be made to views via the view manager. This allows the view manager to "do the right thing" when views are changed. Typically this means minimizing damage repair area and frequency. As mentioned previously, views are arranged in a hierarchy. The relationship of sibling views is maintained through either an absolute z index for each view, or above/below relative to another view. When the view hierarchy is traversed, views are encountered in top down order and from nearest z to furthest z.
The view manager contains a "compositor" which processes the view tree at rendering time to optimally paint the damaged area. This involves determining if any of the layers are "transparent" and then doing back-to-front/front-to-back view processing to repair the damage. Views currently have an opacity property that the compositor will use to alpha blend views together.

2. View class.

This is the base view class and the one generally created by content that requires a view. Examples of such content are CSS positioned elements, Communicator 4 layers, objects that require Widgets such as form elements, etc. Since views are designed to act as containers for content, there is a link to that content which can be set and queried with the Get/SetFrame() methods. When views need to paint or have events handled that do not relate to the view, the frame's Paint() and HandleEvent() methods are called.
In general, views hold state, but don't do much in terms of changing or manipulating other objects. That job is left to the view manager.
Child views are not clipped to the boundaries of their parent views unless a cliprect is specifically set on a view. A clip rect clips the content displayed by a view and any of it's children.

3. Scrolling view.

The scrolling view, which is used as the root level view for NGLayout documents, is essentially designed to act as a container which expects that it's size will be smaller than the views that it contains. It also assumes that the application will want to be able to scroll over the area that is "inside" of it. As such it will automatically sprout scrollbars when the scrolling view is too small to display all of it's contents. It has additional APIs over the standard view to allow the application to get and set the offset into the visible content area and to recompute the size of the scrollbar thumb and position based on the sizes of the objects that it contains.

Dependencies

Currently the view system is tied to the layout system in two places. The first is the previously mentioned Set/GetFrame() method in the view class. The second is layout's Presentation Context which the view manager holds onto and then passes to the Frames in their Paint() methods.
Since views may have Widgets associated with them, and as views change shape they need to tell the Widgets about these changes, there is a dependency on the Widget library.
Much of what the view manager does involves output refresh management so it has knowledge of the graphics system.
Eventually there will be a tie to the DOM/JavaScript for event handling.
We would like to be able to alpha blend views together.

Roadmap

The top priority is to flesh out the compositor so that we can begin displaying more complex documents (CSS-p, layers, etc.) and help to move the layout and style systems toward completion.

Events and the DOM/JavaScript are the next highest priority. As it stands today, all events originate with Widgets attached to views. The widgets inform the views that events have taken place and the views either swallow the events if they don't directly relate to the content (such as a top-level window resize), or pass them on to the frames for processing. JavaScript will most likely need to intervene before events go to frames (for filtering/modification) and after the frames are done with them (in case the frame altered the event).

In order to create any sort of editor on top of the whole system, the view manager will need to participate in the management of selection and an insertion point caret.

Currently, all damage requests to the view manager are coalesced into a single rect which contains the entire damage area. This needs to be improved so that we create a region composed of disparate rects when that would be more efficient. The graphics system needs to provide a working region class first though.

Known Bugs

Scrolling views do not sprout a horizontal scrollbar.
Event handling has not been completely fleshed out. We need to see exactly what the needs of the DOM/JavsScript are in order to figure out exactly what the event flow will look like.
The compositor has a ways to go before it is real. Some code can probably be lifted from Mozilla.
Lack of support for regions by the graphics system means that the view manager region support isn't there either.
There are still some squirrelly little rendering errors when scrolling and resizing.