In RenPresent.hs, the new rendering is compared to the previous one, yielding a diffTree. For a graph, even if the difference is in one of the children, the entire graph is considered dirty, since it is tricky to find out what to redraw if a vertex is updated. For the moment, even if a presentation of a vertex is changed, the entire graph is marked dirty. Maybe this can be relaxed in the future.
In the diffTree, the old and new focus are marked, by marking the common prefixes of the from and to paths as dirty. For graphs, again the entire graph is made dirty, because the focus on a vertex may extend the presentation of the vertex (and may be covering edges and other vertices.)
On rendering, only the elements in the arrangement tree, that have a diffTree node stating that self is dirty are rendered.
DiffNode childAndSelfClean selfClean
check out what selfDirty means for composite presentations
When the presentation is presented (detokenized)Explain how the diffTree is created.
Pruning the presentation
Prune according to diffTree only. Clean subtrees are replaced by arrangedP nodes.
On arrangement of an ArrangedP
if the old arrangement for ArrangedP
overlaps with the current viewedArea
and the position of ArrangedP
is the same as the position of the corresponding old arrangement
and the viewArea has not changed
and the old arrangement contains unArranged elements
then re-present the subtree at the ArrangedP
Poly (IDA (-10) ..)
is currently used to denote unarranged arrangements. An
should be added to the
To avoid allocating space for attributes, the subtree is only put in the tree when needed, in the form of a higher order attribute. The information is taken from the unpruned tree, which is passed along the pruned tree as an attribute @lhs.unprunedTree.
Still problematic when
nodes are children of a presentation that was not arranged. In that case, there is no corresponding old arrangement with correct size information. To tackle this problem, we keep track whether
is valid, and if not, all attributes for
are taken from the higher-order presentation attribute.
- Position changes should take into account absolute positions, and not relative.
The incremental arrangement algorithm replaces presentations that were unchanged in the last edit cycle by
leafs, for which the old arrangement is used during arranging. At the moment, the old arrangement is passed as an argument to the arrangement AG, and traversed in parallel to the presentation. When an ArrangedP
leaf is encountered, the old arrangement is used.
The arranger does not create arrangements for subtrees that are not in view. This has a very subtle interaction with the incremental arrangement algorithm.
newly uncovered parts of the arrangement
If an arrangement was out of view, and is still out of view, there is no problem, as the reused arrangement is empty but it will not be in view. Similarly, if an arrangement was in view and is still in view, its reused arrangement will be correct. However, if the arrangement was out of view, but is placed in view because of a scroll operation, or a different position in the arrangement (e.g. when something in front of it got smaller) then the reused arrangement will be empty. Hence, if a presentation is clean, prunePres checks whether it overlaps the uncovered area, and does not prune the presentation when it does.
TODO: check whether arrangement coordinates will always correspond to presentation coordinates. If a parent had a dirty child appearing in front, this might not be the case.
The information in the
is based on indices in the formatter, but the old arrangement contains a column of rows. This mismatch requires special handling of formatters in the prunePres algorithm and in the arrangement AG.
- formatter with arrangement that has poly's for column or one of the rows cannot use old arrangement.
- in ag, reuseing old arr at formatter unfolding requires gathering children from rows in column.
- at arrangement of unfolded column of rows, structure of old column of rows is mapped on new column of rows.
- Find out what happens with backgrounds
- Find out when incrementality incorrectly prevents rearrangement.
- 18 Jan 2008