Understanding InfiView Space
Here we will explain how the memory management system is designed and how InfiView is able to handle so many nodes at the same time. If you are building an application that will hold a large number of nodes (thousands); information in this document will of great use to you. We will also explain about InfiViews coordinate systems and how its viewport component works and talk about light weight states of components.
Nodes and Visual Representation
The visual representation normally consists of Bindows component. Normal Bindows components, although highly optimized, still has a lot of memory consuming overhead inside them. They contain many functions for e.g. event handling and many properties that is why InfiView use a lightweight representation called a node that contains logic to show and hide (dispose) the visual representation.
The node contains a property map called persistent data map that holds information of this specific node and makes it possible to keep necessary information intact when the visual representation of the node is removed.
The Viewport together with its model is your playground in InfiView. This is where nodes gets added and removed, live and dies. You treat the viewport as you would any Bindows component. You give it size and color and add it to your window or put it inside other Bindows components.
Inside a viewport is a massive, potentially infinite, space. You dont have to specify the size of this virtual space. You can just add nodes to it at any coordinate, even negative coordinates. Therefore; positions or coordinates inside the viewport have nothing to do with screen coordinates.
Under the Hood of the Viewport
Besides the visible area in the viewport there are other virtual areas that you might need to be aware of if you are to understand some of the terminology used in the API documentation. The different areas or layers are illustrated below:
View of the different areas used by InfiView: (1) Visible area, (2) Render area, (3) Content, (4) World area. The small rectangles indicate components. Pink rectangles are components that are currently being rendered and shaded rectangles represent components that are currently not being rendered.
Visible Area (1)
This is what fits on the screen and components located in this area are always rendered - visible on screen. The size of the Visible area is always has the same size as the viewport itself takes up. Components inside the visible area take up memory (represented by a div tag). By default; position 0,0 of the visible area is located at position 0,0 in the World Area.
Render Area (2)
This is a cache area just outside the visible area. Components in this area are always rendered. If the visible area is translated (moved) into the render area then components that reside here are quickly displayed. Components in this area take up memory. As the visible area moves, the render area moves with it.
Content Area (3)
This is another cache area similar to the render area except that components that live here are not rendered. They are however fully ready to be rendered in case the render area would translate into the content area. As the render area moves, the content area moves with it. If you have a lot of components outside the visible area it might be a good idea to limit the size of the content area to improve the performance. If you don't have many components you might get away with having them all in memory, ready to be rendered and could therefore make the content area very large.
World Area (4)
This is the rest of the viewport's area. The size of it grows or shrinks as needed to accommodate for new nodes that you add to the viewport. Nodes that reside here are not rendered and take up nearly no memory at all. This is what gives InfiView the ability to have so many nodes seemingly loaded. Scrolling into this area will however create visual representation of the nodes residing here and dispose the visual representation on nodes that ends up outside the "content area".