| 44 | * Logging: |
| 45 | * Performance problems found |
| 46 | * EdgeKind.findLayoutHillClimb logs the Vertex on each step of the algorithm. This log includes all VertexKinds with their values. |
| 47 | * HotTextLayout.draw logs the Edge on each transition between two vertexes, including the Vertexes with their properties. |
| 48 | * Both loggings result in a large amount of very long strings, making them not usable. |
| 49 | * These logs are usually not interesting for tracing or for tracking bugs. |
| 50 | * Solutions |
| 51 | * Modify EdgeKind.findLayoutHillClimb to log only the EdgeKinds to track the correct work of the layout algorithm. |
| 52 | * Modify HotTextLayout.draw to log only the path size. |
| 53 | * Further logs will be introduce on demand. |
| 54 | * Measured performance improvement - around 20% |
| 55 | * Implement methods marked as fake and/or performance: |
| 56 | * ImmArea.contains method added. Atom.canFit method modified to use it. |
| 57 | * Modify Vertex methods getMinX, getMaxX, getMinY, getMaxY to cache the min and max coordinates. |
| 58 | * Measured performance improvement - 2-3% |
| 59 | * Check for existing useless updates and reflowing: |
| 60 | * Cases pending improvement after implementation of [wiki:GROUP_CHANGES_R0] in relation to Layout performance. |
| 61 | * Usage of text resource: |
| 62 | * resource.text().get().replaceText(newText) results in reflowing of the text on each character from the new text. |
| 63 | * resource.text().set(newText) results in reflowing of the text only once. |
| 64 | * All problematic occurrences of the first case are replaced by the second, but this is still error prone until solved by group changes. |
| 65 | * In PageElementLogic.SELECT_DESELECT_PAGE_ELEMENT.handle the call pwa.allSelectedElementViews().get().clear() results in numerous updates and reflowing of text. |
| 66 | * To be solved with group changes. |
| 67 | * Performance improvement: Add a check if the frame needing selection is not already the only selected frame. |
| 68 | * Measured performance improvement - 0% for the layout itself, but less calls to it in some specific cases. |
| 69 | * Refactor the Layout algorithm |
| 70 | * Change Atom implementation |
| 71 | * Create a new static abstract class AtomKind inside Atom to: |
| 72 | * Encapsulate usage of effective units (Atom.effUnit and Atom.units moved to AtomKind). |
| 73 | * Replace the fake solution using a single unit with a real one allowing managing of atoms with a bigger size (with multiple units). |
| 74 | * Have functionality to switch internally to the next consecutive AtomKind if the current does not provide a good implementation |
| 75 | * Create inside AtomKind new private static classes subclassing AtomKind to provide different management of unit chunks |
| 76 | * UnitKind - represents the simple management of units |
| 77 | * The atom contains only one unit. |
| 78 | * This is the same as the current implementation and is needed if the other kinds do not provide a solution for a specific case. |
| 79 | * WordKind - represents the management of units by words |
| 80 | * The atom contains grouped units ending at a separator. |
| 81 | * Will decrease the number of steps of the algorithm when separators exist in text on a regular basis (which should be the common case). |
| 82 | * SentenceKind |
| 83 | * The atom contains grouped units ending at a line, paragraph or document break. |
| 84 | * Will decrease the number of steps of the algorithm when breaks exist in text on a regular basis |
| 85 | * This is often not the case, so this kind will produce worse performance in a lot of cases. |
| 86 | * If useful cases are localized during implementation and it does not affect others it will be preserved (and design will be updated). |
| 87 | * Remains as optional. |
| 88 | * Optionally add other Kinds, following the idea to split the units in chucks relative to the bounds of the frame. |
| 89 | * Design will be updated if implemented. |
| 90 | * Add Atom.kind field to keep the current AtomKind of the atom. |
| 91 | * Note: The notion of a kind is kept internal for the atom. The client code has simply an interface to decrease the atom's size. |
| 92 | * Add Atom.decreaseSize method to trigger the switching to the next AtomKind. |
| 93 | * Modify EdgeKind.SEGMENT and EdgeKind.OPEN_LINE to use Atom.decreaseSize if the atom can not be placed with its current size (that is, with its current kind) |
| 94 | * Measured performance improvement - 10% on average, depending on the specific text. To be improved further during the implementation phase. |
| 95 | * Test: [3608] |