Last modified 15 years ago
Last modified on 11/16/09 17:08:55
Analysis
Overview
The general performance of Sophie2 is not good enough. These operations are considered slow:
- Editing the text of a frame / chain;
- Moving, resizing, rotating a frame;
- Changing the z-order;
- Opening a large book from a file;
- Opening book preview (even of an empty book);
Task requirements
- A halo menu and its children should not compute anything if it's not visible. The current version of Sophie without halo menus is much faster and this means that halos perform lots of computations even if not used.
- Not every book needs a halo menu itself. The halo menus should be common for the application.
Task result
Better performance of the application in general.
Implementation idea
- In order to make the visibility requirement, VisualElements need to know about their visibility. This means adding a new prop to the interface.
Related
NFR_PREVIEW_PERFORMANCE_R0
NFR_TEXT_PERFORMANCE_R0
How to demo
Start a previous and the current versions of sophie, compare the speed of the above mentioned operations in both applications.
Design
Visibility
- Add Prop<Boolean> visible() in VisualElement;
- Override the method in BaseVisualElement, like this: if (parent().get() == null) return true; return parent().get().visible().get() && computeVisible();.
- This way, a visual element will not be visible unless all its parent are also visible.
- Create protected boolean computeVisible() in BaseVisualElement, which returns true by default. This will cause some conflicts because of overrides, returning Boolean. Solve them :)
- In most of the needed cases, this method is overriden already and no more work is needed. This considers halo menus. However, look around for possible problems.
- In BoundControl, add protected abstract M getDefaultValue(). This will be implemented in subclasses, according to their type. It will return the value which will be used when nothing in computed.
- Again in BoundControl, in computeModelData(), if the control is not visible, return the default value.
- Result: a bound control will not recompute if not shown. For example, writing text in head text frame is smoother.
Halo menus
- Currently, the halo menus of a book contain about 170 bound controls. They are created and initialized every time a new BookDocView is opened.
- If we want the halo menus to be in the main window, this means they will not have a parent of type PageWorkArea. Find all the findParentElement(PageWorkArea.class) and replace them with AppHaloUtil.getWorkArea(). The same about the static alternative of this method.
- Find all findParentElement(BookDocView.class) and replace them with appropriate logic (for example, get the parent of the workArea).
- Refactor the AppHalotil.getWorkArea(VisualElement element) so that it looks like: return AppViewUtil.getCurBookDocView(element).workArea().get().
- Move the prop haloMenus() from PageWorkArea to AppMainWindow.
- Change the visualElementDefs of all the halo menus so that their parent will be of type AppMainWindow.
- Move the part related to halo menus from the setup methods in the swingComponent() in PageWorkArea to a resource prop in AppMainWindow.
- The new setup must firstly remove all the halo components from the halo layer of the last previous and the current PageWorkArea. Otherwise, the swing will not work properly.
- Result: faster book opening, preview opening (about 5 sec), less memory usage.
Implementation
Done in branches/private/milo/prop-opt.
Merged to the trunk at [8131].
Testing
(Place the testing results here.)
Comments
(Write comments for this or later revisions here.)