View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017776 | MMW 5 | Main Panel | public | 2021-04-20 18:04 | 2021-05-12 21:50 |
| Reporter | drakinite | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0.1 | ||||
| Target Version | 5.0.1 | Fixed in Version | 5.0.1 | ||
| Summary | 0017776: Performance issue - Loading a large album in grid view causes entire view to lag, even after it is collapsed | ||||
| Description | Because all of the listview items are hidden out of view by their position, instead of having display: none, Chromium spends a ton of computation time updating the layer tree because of all those divs being loaded. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2400 | ||||
|
|
Fixed for 5.0.1 (Also changed "new Date().valueOf()" to "Date.now()" because the latter is marginally faster than the former). |
|
|
Changes caused a regression (0017783); temporarily reverted changes until the latter issue can be identified |
|
|
ok, there have been some further regressions that I noticed (and that this revert fixed). On empty database: 1) Music [Browser view] shown icons for the empty Artists/Albums rows 2) Properties > Classification > Playlists: shows UI artifacts when there is no playlist to which the track belongs i.e. empty grids/lists were not shown as empty |
|
|
Fixed in build 2400. |
|
|
Changes introduced another regression in which the now playing list is not positioned properly when the window initially loads. Fixed in revision 37875 |
|
|
Verified 2400 I can't replicate LAG anymore in 2400 |
|
|
Re-verified 2404. Closing. Note that opening a large album in the grid view does still cause lag because of the enormous number of divs, but after closing it and opening another album, the lag goes away (which was the original issue). |
