Poor performance scrolling playlist folders in library

[mixxxbot]

Reported by: nikmartin
Date: 2017-09-25T22:30:47Z
Status: Fix Released
Importance: High
Launchpad Issue: lp1719474
Tags: library, midi, performance

---

When I'm performing I use my controller to scroll through crates and playlists. My controller is a Pioneer DDJ-SB2 and I use the built in mapping that uses Shift + Browse encoder knob to scroll between folders and tracks. When I hit the playlist section of the library, and am scrolling down the list of folders, mixxx, will start to slow, and get 'hung up', so badly that even the waveforms will freeze. The playback so far has never been affected. If I stop, the scrolling will eventually catch up, but typically will have scrolled all the way to the top as a side effect of me scrolling while it's hung. It seems to be the worst when in the playlist folder, where I have a dozen or so playlists. It is glitchy in the crates folder too, but not nearly as bad.

This is on 64 bit Arch Linux, on the master branch built from source, using a Pioneer DDJ-SB2 controller and Tango Skin. Built only using optimize=native flags, so qt4. CPU is a quad core Intel i5. Video is built in intel. 8 gb ram.

[mixxxbot]

Commented by: esbrandt
Date: 2018-03-23T15:20:24Z

---

Can confirm with latest git version, and Vestax VCI 300 on macOS 10.3.3

It becomes so slow, it is basically unusable - not only after some time, but right after launch.

[mixxxbot]

Commented by: ronso0
Date: 2018-04-14T17:40:49Z

---

Sadly I noticed this yesterday with Tango skin: as soon as the scrolling waveforms are hidden the Library interaction via controller is very slow and after pressign the waveform toggle waveforms take some seconds to show up.

Hardware is a Thinkpad X220 with Intel HD Graphics 3000.
Ubuntu Studio 16.04 low-latency, everything is updated
RGB (GL) and (GLSL) tested.

Probably this was bug was introduced when I fixed
lp:1746110 "No end of track warning if Waveform Display not enabled on Tango Skin" and lp:1748170 "Log file grows rapidly" with #1512

I'll investigate if this can be solved by placing the second waveform Singleton somewhere else or with different size.

[mixxxbot]

Commented by: ronso0
Date: 2018-04-14T17:42:39Z

---

the issue does not show up on my Thinkpad E525 which has a Radeon graphics card.

[mixxxbot]

Commented by: uklotzde
Date: 2018-04-16T15:40:17Z

---

This is not a graphics/display issue but rather caused by repeated and synchronous database access while selecting multiple playlists in a row:

https://www.reddit.com/r/DJs/comments/8cku9r/mixxx_21_released_with_revamped_skins_and_effects/dxg7unh/

Finally I got it ;)

We should try find a workaround at least for 2.2. and maybe also for 2.1.x. This will affect all users that use the encoder for scrolling through the left pane! I usually grab the mouse for this purpose and only noticed it recently while updating my mapping.

[mixxxbot]

Commented by: uklotzde
Date: 2018-04-16T15:48:41Z

---

Uptime of Mixxx should not affect the issue. The performance of database queries does not depend on how long the application is running, at least I've never noticed any degradation for search and crates. Queries on creates should be efficient since the refactoring in late 2016.

[mixxxbot]

Commented by: uklotzde
Date: 2018-04-16T15:55:33Z

---

Possible workaround for 2.1.x/2.2:

Don't load the content of playlists and crates immediately after selecting the corresponding item. Instead remember the selection and start a timer that expires after a few milliseconds. The timer is cancelled and restarted if the selection changes while the timer is still running. If the timer expires and the selection is still valid then finally load the contents and update the view.

[mixxxbot]

Commented by: nikmartin
Date: 2018-04-16T18:22:37Z

---

Uptime of Mixxx should not affect the issue.

Yes, I think my observation is incorrect; I think it is as slow on startup as it will ever be.

[mixxxbot]

Commented by: uklotzde
Date: 2018-04-16T20:47:18Z

---

Gave it a try and the proposed workaround works perfectly! Only a few lines of code.

I will implement the timed selection for both crates and playlists. Then we can decide if we release the fix with 2.1.1 next weekend.

[mixxxbot]

Commented by: uklotzde
Date: 2018-04-16T20:54:16Z

---

A delay of ~50 ms seems to be a good compromise between responsiveness when selecting individual items and smooth scrolling.

[mixxxbot]

Commented by: uklotzde
Date: 2018-04-16T20:59:35Z

---

I correct: ~100 ms is more appropriate

[mixxxbot]

Commented by: nikmartin
Date: 2018-04-16T21:41:47Z

---

If you have a fork/branch I'd be glad to test as well on my controller and somewhat underpowered (i5 1.2 gHz) laptop.