|
|
Note: Need to look into layout thrashing in the tab switching animation. image.png (57,337 bytes) |
|
|
Added in 5.0.3. This one includes a lot of changes, so it's quite possible that it introduces regressions. - I tried to utilize the new queryLayoutAfterFrame() and applyStylingAfterFrame() callbacks for the ListView, but it's an absolute behemoth and I think it'd need a lot of refactoring. Put the part in _adjustSize that sets viewport.style.height/viewport.style.width into an applyStylingAfterFrame call, but it broke dropdowns. I made a hacky fix by adding a ignoreReflowOptimizations parameter to the ListView initialize method. It would be preferable to find a less hacky fix in the future. - controls/artWindow.js contains a good example of how to best utilize the functions. adjust_transparency_prepare() caches all necessary CSS values for a layout change, and adjust_transparency_apply() applies the transparency adjustments. - Some refactoring of splitters to minimize the amount of sibling calculations it needs to make (Added notifySplitterChange() as a last resort way to force splitters to recalculate everything, in the event of a major change like showing/hiding the column filter) - Removed old/unused code in docking.js - Changed most instances of setVisibility to setVisibilityFast in the navigation bar, b/c AFAIK we don't need any JS layout recalculations |
|
|
I had to revert several parts of your revision as it caused regressions: 1) unit tests failed after replacing this.requestFrame > queryLayoutAfterFrame (line 1792 in ListView.js) Reasons described over IM (i.e. control context versus global context issues and non cancelled frame callback when ListView has been already destroyed) 2) When ignoreReflowOptimizations was false then the LVs often haven't been drawn at all, example in Sync-list (when switching the collection nodes on the left) then the sub-nodes on the right were often empty => reasons described over IM |
|
|
Re-introduced the Jordan's changes + fixed real reasons for the regressions in 5.0.3.2600 |
|
|
Removed some changes in tabs in 5.0.3.2600, we need layoutchange event when changing visibility of tab panel, it can contain e.g. LVs, which display their contents after visibility change. |
|
|
Re-opened for further changes/improvements discussed offline with Jordan |
|
|
FYI: I implemented queue for the frame callbacks (be it global and local frame callback) to be executed at once and then applying all the layout and styling callbacks (see my SVN revision 39264). But subsequently I had to revert the changes because of strange drawing regressions, apparently somehow related to the order of the individual frame callbacks. Needs to be figured out, but it seems that any change in this area is very risky and possible regressions hard to find and debug so I am not sure that it worth to spend further time on it atm. Also when dragging the splitter between the right side panel the layout calculations does not seem to perform any better (based on measurements in DevTools > Performance). I haven't tested switching tabs, but it seems to me that the optimizations that you are trying to achieve are very minor against possible problems and complications that it is bringing. More discussed via IM... |
|
|
As discussed via IM, we'll resolve for now. It seems like overhauling the way we render everything is a bit too much at this stage in development. But as it stands for the time being, the performance is much better than it was before. |
|
|
As talked offlike I reverified original behavior with one in 2619 and I agree with @drakinite that for the time being and for 5.0.3 release we have done as much as possible to improve behavior. 0018562 will further improve that, So I am closing this one. |
- Anonymous
