replicator.org ... continuous garbage collection

Now that spatial queries are implemented, the Presentation Layer needs to access the Visuals stored in the R-Tree. The Presentation Layer consists of separate classes that handle the distinct visual layers. These are the Nodes, the Connectors, and the Labels. Additional layers are used for overlays and prototype Visuals, but these are not of importance right now.

BrainSharper supports dragging the whole canvas at once. Zooming is not yet supported, but will be soon.

Right now, the Presentation Layer receives the events that are dispatched by the domain and realizes them by creating or modifying (WPF) control objects. Obviously, this is a push-model: The domain pushes the events to the user interface.

To change the Presentation Layer from a stupid “I present you all Visuals” Canvas to one that manages the only the Visuals inside the Viewing Area, the following components need to be created:

• First of all, a component that can retrieve and present the Visuals directly from the R-Tree is needed. For the lack of ideas I call it the “Visual Presenter”.
• Another component, that coordinates the viewing area rectangle must be introduced. This component computes the model rectangle and forwards the dirty rectangles to the “Visual Presenter”. I will call that class the “Viewing Area”.
• A component that flushes unused visuals needs to be built. This component runs when the user is idle and instructs the visual layers to free Visuals that are not inside the viewing area. ”Visual Collector” is probably a nice name for it.

Additionally, I decided to split up the layer classes into a controlling part, that handles all domain events, and a viewing part, that displays the controls.

All in all, the Presentation Layer is going to morph towards a more pull-oriented nature. It watches the domain events to get notified when something changes. And whenever the view area changes, it queries the missing Visuals directly from the database.

Below is a rough visualization that covers only the node layer:

Some details of the implementation:

Visual Presenter

The Visual Presenter queries the Visuals from the R-Tree table. Obviously, this takes some time depending on the number of visuals that intersect with the Viewing Area. On my computer, the queries run in sub-millisecond time, but to avoid lags on slower computers, I decided to decouple the queries from the main thread. This should improve the scrolling experience, but may cause new Visuals to pop in while the user is dragging the document.

Visual Collector

Another advantage of introducing a Worker Thread, is that the Visual Collector can also use it. I’ve decided to implement the Visual Collector in a similar way like the Presenter: As soon the Viewing Area has changed and the user is inactive for some time, the Visual Collector runs a background task to find out what Visuals should be displayed inside the viewing area. It then instructs all layers to hide Visuals that are not visible. Of course, the Layer Views could decide autonomously to hide the visuals that are not inside the viewing area, but I wanted that the Presenter and the Collector use the same rectangle information for the intersection tests. This guarantees that the two mechanisms don’t contradict in their decisions. Another advantage is that the Presenter and the Collector are both independent of the user interface framework.