View Issue Details

IDProjectCategoryView StatusLast Update
0018600MMW 5Generalpublic2024-01-11 16:02
Reporterdrakinite Assigned To 
PriorityurgentSeverityminorReproducibilityN/A
Status closedResolutionsuspended 
Product Version5.0.3 
Fixed in Version5.0.3 
Summary0018600: [Performance] Improve tab switching animation & reduce forced reflow
DescriptionAs of 0018562, switching tabs no longer requires layout recalculations. We can now make the tab switching animation much smoother by removing the layout recalculation.

Layout change handlers include a lot of forced reflow, i.e. querying a style change, applying a new style change, then querying the style change again. This process leads to significant lag. For non-blocking UI changes, we should have the option to query a style after the rest of the frame has been calculated, and additionally, the option to apply a style after the query callbacks have been fired:
- queryLayoutAfterFrame()
- applyStylingAfterFrame()
TagsNo tags attached.
Fixed in build2601

Relationships

related to 0018562 resolvedrusty Tabs don't share the same layout 
parent of 0018821 closeddrakinite Right side bar: It can't be resized after hide/unhide (regression 5.0.3) 
related to 0018901 closedmichal Visualization doesn't use full available window height 
related to 0020403 closedmichal Artwork doesn't resize with panel width in Album Art view in Playing (first time) 

Activities

drakinite

2021-12-11 16:39

developer   ~0066356

Note: Need to look into layout thrashing in the tab switching animation.
image.png (57,337 bytes)   
image.png (57,337 bytes)   

drakinite

2022-01-04 19:51

developer   ~0066514

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

Ludek

2022-01-06 15:14

developer   ~0066528

Last edited: 2022-01-06 15:39

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

Ludek

2022-01-06 16:26

developer   ~0066529

Re-introduced the Jordan's changes + fixed real reasons for the regressions in 5.0.3.2600

michal

2022-01-06 17:24

developer   ~0066530

Last edited: 2022-01-06 17:24

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.

Ludek

2022-01-07 19:33

developer   ~0066580

Re-opened for further changes/improvements discussed offline with Jordan

Ludek

2022-01-08 17:27

developer   ~0066587

Last edited: 2022-01-08 17:46

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...

drakinite

2022-01-09 06:06

developer   ~0066590

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.

peke

2022-05-01 23:12

developer   ~0067912

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.