Severe UI lockups under OS X

[mixxxbot]

Reported by: tildearrow
Date: 2018-03-28T00:09:19Z
Status: Fix Released
Importance: High
Launchpad Issue: lp1759433
Attachments: [heaviest stack trace](https://bugs.launchpad.net/bugs/1759433/+attachment/5093392/+files/heaviest stack trace)

---

It is almost impossible to use Mixxx under OS X 10.11, because:

1. Scratching isn't fluid anymore.
2. Playing more than 1 deck at a time makes the UI extremely laggy (mainly in Tango skin) (the UI appears to be smooth but clicking anything will cause Mixxx to ignore the input event for several seconds).
3. (apparently disabled now) If I click any field in the library (say, to change a song's name/artist), the UI goes down to 2 FPS.

System Information:

OS X 10.11.2, MacBook Pro (13-inch, Mid 2012), 2.5 GHz Intel Core i5, Intel HD Graphics 4000.

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-28T00:26:55Z

---

Are you using a controller or timecode vinyl to scratch? The responsiveness of both is tied to the audio buffer size in the Sound Hardware Preferences. A smaller buffer will be more responsive.

Regarding #⁠3, we are currently discussing how to handle this on GitHub:
#1561 (comment)

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-28T01:02:56Z

---

I'm not using any of these. Using a smaller buffer seems to only hurt the situation even more.

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-28T01:14:42Z

---

How are you scratching then? Clicking the waveform?

Have you tried different options for the waveform renderer in the Waveform preferences? Also, have you tried adjusting the waveform framerate?

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-28T01:27:39Z

---

Slowly dragging the waveform from right to left. The scratching stops constantly, then jumps.

Any waveform renderer will reproduce.

Doesn't reproduce if FPS is set to 15 or lower, but that's no longer smooth...

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-28T02:35:31Z

---

Possibly related:
#1510
#1547

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-28T03:40:19Z

---

When did this start?

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-28T04:06:20Z

---

This bug is present since I began to try Mixxx 2.1, I think.

[mixxxbot]

Commented by: esbrandt
Date: 2018-03-28T10:01:55Z
Attachments: [heaviest stack trace](https://bugs.launchpad.net/mixxx/+bug/1759433/+attachment/5093392/+files/heaviest stack trace)

---

This is always very heavy on OSX https://github.com/mixxxdj/mixxx/blob/master/src/mixxxapplication.cpp#L180

#76 (diff)

[mixxxbot]

Commented by: daschuer
Date: 2018-03-28T11:07:05Z

---

This one might be considered as a release blocker.
Do we have a clue at which percentage Mac installations are effected?
Does it depends on the qt version?
Does it depend on the build settings / environment.

@tildearrow: did you use the packages from
http://downloads.mixxx.org/builds/2.1/release/

Is the oldest version of this side effected as well?
Are builds from
http://downloads.mixxx.org/builds/master/release/

Also effected? Please list the versions you have tried and the results.
Thank you!

[mixxxbot]

Commented by: daschuer
Date: 2018-03-28T12:26:49Z

---

@jus: are you able to reproduce the issue?
Did the issue happen during your trace?

We reimplement notify() to catch special events for touch handling. Without Mixxx code QApplication::notify(target, event); will be called directly. 
So if our issue is related to this. We must have done a kind of event loop in the code above. We may create a version without MixxxAoplication::notify ()

In this area Qt5 has changed a lot. Maybe only the qt5 version is effected?

[mixxxbot]

Commented by: esbrandt
Date: 2018-03-28T12:43:10Z

---

@daschuer
Yes, can basically confirm the issues as described by tildearrow . Other symptoms are possibly lp:1719474. The specs on my machine are somewhat lower, but pretty similar to tildearrow´s ( macOS 10.13.3 MBP late-2011 Intel Core i5 2.3 GHz 8 GB Intel HD Graphics 3000)

The trace was right after launch, mixxx idling with no track loaded. Still poor performance when somehow utilizing the library. I found that disabling the tooltip brings at least some of the responsiveness back.

My build is using qt4.

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-28T12:54:31Z

---

Macs don't have touchscreens, so we may consider hacking around this by excluding MixxxApplication::notify from Mac builds.

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-28T14:07:23Z

---

@daschuer Yes, I did.
I will provide a list of versions I tried in some hours since I am not at home ATM.
Also I will try building Mixxx with the other Qt version to check if it is affected too.

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-28T20:33:49Z

---

OK, so I've tested on Mixxx 2.0, and it seems to reproduce too, but apparently only during track analysis.
Also tested on:

• Mixxx 2.1-r6501 (only under track analysis, high CPU usage or 3+ decks)
• Mixxx 2.1-r6505 (reproduces with at least 2 decks)
• Mixxx 2.1-r6530 (sometimes reproduces)

(all builds downloaded from mixxx.org)

[mixxxbot]

Commented by: daschuer
Date: 2018-03-28T21:10:11Z

---

Thank you very much. It sounds like that it is quite hard to say reliable if a version changes the issue or not.
Can we assume that the issue was already there with Mixxx 2.0?
If yes, this bug is not a release blocker and can go into a point release once we have a solution.
If it is a regression since 2.0 it is a release blocker.

The questionable touch code was introduced here:
#76
before releasing 2.0

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-29T03:38:16Z

---

Just did a quick test with 1.11. The UI's graphics do lag a little, but input is very responsive.
This means, I'm sorry, but this bug is most likely a blocker...

[mixxxbot]

Commented by: daschuer
Date: 2018-03-29T06:09:18Z

---

This means we had this issue in 2.0 as well.
So no blocker for 2.1 because things are not getting worse.

Can you try this one, by building yourselves?
#1566

Be has removed the touch workaround, that was introduced in 2.0. If this fixes your issues, it would explain the GUI lag since 2.0

[mixxxbot]

Commented by: daschuer
Date: 2018-03-29T06:19:25Z

---

https://bugs.launchpad.net/bugs/1701441
This one can also be related.
Which scaling factor do you use?

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-29T20:03:39Z

---

Then you probably meant to say "2.1" in "If it is a regression since 2.0 it is a release blocker.".

Sure, I will try compiling and testing as long as I can.

1x scaling, by the way.

[mixxxbot]

Commented by: daschuer
Date: 2018-03-29T20:15:34Z

---

Ah yes. Thank you for your support.

Can you reproduce a GUI lag after editing a track within the library?
Click an already selected Track.

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-29T20:20:27Z

---

scons stdlib=libc++ hss1394=0 mad=0 faad=0 coreaudio=1 verbose=1 qt5=1 -j2:

src/mixxx.cpp:117:23: error: member 'create' found in multiple base classes of
      different types
        StatsManager::create();
        ~~~~~~~~~~~~~~^
/usr/local/Cellar/qt/5.10.1/Frameworks/QtCore.framework/Headers/qthread.h:234:19: note: 
      member found by ambiguous name lookup
QThread *QThread::create(Function &&f)
                  ^
src/util/singleton.h:9:15: note: member found by ambiguous name lookup
    static T* create() {
              ^
src/mixxx.cpp:117:23: error: C++ requires a type specifier for all declarations
        StatsManager::create();
                      ^
src/mixxx.cpp:117:29: warning: empty parentheses interpreted as a function
      declaration [-Wvexing-parse]
        StatsManager::create();
                            ^~
src/mixxx.cpp:117:29: note: replace parentheses with an initializer to declare a
      variable
        StatsManager::create();
                            ^~
                             = 0
210 warnings and 2 errors generated.
scons: *** [osx64_build/mixxx.o] Error 1
scons: building terminated because of errors.

I can't build it. Can anyone provide a build?

[mixxxbot]

Commented by: esbrandt
Date: 2018-03-29T20:29:26Z

---

@tildearrow
https://bugs.launchpad.net/mixxx/+bug/1749800/comments/21 might help building with QT4 (Mixxx default)

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-29T20:34:59Z

---

Never mind. I worked it around by disabling the stats manager.

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-29T20:43:02Z

---

OK, so this Qt 5 UI is lagging very hard on my machine.
The controls are a little more responsive, however.
I'll try to build with Qt 4 in a few hours.

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-29T21:17:59Z

---

Whether this was introduce in 2.0 or after 2.0 does not matter. It is a release blocker.

[mixxxbot]

Commented by: daschuer
Date: 2018-03-29T22:05:02Z

---

It does matter, because if we release 2.1 introducing this bug, we break Mixxx for Mac users.
If we have already a broken Mixxx Version out there for some users, we actually improve it with the nice 2.1 features. There is no reason to delay that.

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-30T00:12:12Z

---

OK, so I built Mixxx 2.1 with Be's fixes with Qt 4. I still can reproduce the issue (both issues, the input lag one and the library slowdown one) :(

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-30T00:12:41Z

---

Wait a second, pardon me. I built the wrong branch. I'll switch branches and try again.

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-30T00:43:56Z

---

OK, so I built the correct branch now, but it still reproduces (although a little less). I can't change track properties in the library by clicking.

[mixxxbot]

Commented by: daschuer
Date: 2018-03-30T00:54:10Z

---

You need to enable it in the library preferences.

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-30T01:52:18Z

---

I see. The slowdown no longer occurs.

[mixxxbot]

Commented by: daschuer
Date: 2018-03-30T07:45:01Z

---

Great. So I think we have a release candidate.
Thank you for investigating.

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-30T11:16:04Z

---

I will try to borrow a Mac today to confirm this.

[mixxxbot]

Commented by: tildearrow
Date: 2018-03-30T14:38:51Z

---

Wait. By "the slowdown no longer occurs" I mean that trying to change a track's properties in the library no longer slows down the UI,
but the input lag when playing 2+ decks is still there (though a little reduced).

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-30T18:07:02Z

---

Testing with a MacBook Air (11-inch, Early 2015), 1.6 GHz Intel Core i5, 4 GB 1600 MHz DDR3, Intel HD Graphics 6000 1536 MB, I can reproduce this with Tango and LateNight but not with Deere. Trying to load Shade crashes Mixxx.

[mixxxbot]

Commented by: daschuer
Date: 2018-03-30T19:31:16Z

---

Which scale factor do you use? Can you produce a backtrace?

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-30T23:14:42Z

---

I could not reproduce this with a new Macbook (15 inch, 2016):
Model Name: MacBook Pro
Model Identifier: MacBookPro13,3
Processor Name: Intel Core i7
Processor Speed: 2.6 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 6 MB
Memory: 16 GB
Boot ROM Version: MBP133.0238.B00
SMC Version (system): 2.38f7

but with an older Macbook Air (13 inch, mid 2011) I reproduced it:
Model Name: MacBook Air
Model Identifier: MacBookAir4,2
Processor Name: Intel Core i5
Processor Speed: 1.7 GHz
Number of Processors: 1
Total Number of Cores: 2
L2 Cache (per Core): 256 KB
L3 Cache: 3 MB
Memory: 4 GB
Boot ROM Version: MBA41.007B.B00
SMC Version (system): 1.73f66

The affects LateNight and Tango but not Deere. When the waveforms are hidden in LateNight and Tango, the UI becomes responsive. I tried the various waveform renderers and it occurs with RGB GLSL and RGB GL renderers, but not plain RGB (CPU rendering). Using the RGB renderer is not a good workaround though because the waveform gets really choppy.

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-31T01:26:17Z

---

My friend is letting me borrow his old Macbook Air, so I'll try to figure out a solution to this in the next few days.

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-31T23:39:41Z

---

Doing a Git bisect traced the problem with Tango to commit e73d9d4.

[mixxxbot]

Commented by: Be-ing
Date: 2018-04-01T01:57:21Z

---

Reverting the level meters to raster graphics in LateNight and Tango works around the problem:
#1573

[mixxxbot]

Commented by: tildearrow
Date: 2018-04-01T03:40:05Z

---

I just pulled your branch again to test, but I can still reproduce the input lag when playing all 4 decks at once and spamming UI buttons.

[mixxxbot]

Commented by: Be-ing
Date: 2018-04-01T03:55:01Z

---

You might be encountering this issue: Bug #⁠1406937

Try running mixxx with the --resourcePath command line option specifying the resource path in your Git repository. For example, if your Git repository is at ~/sw/mixxx, run "mixxx --resourcePath ~/sw/mixxx/res"

[mixxxbot]

Commented by: Be-ing
Date: 2018-04-01T04:00:28Z

---

My branch only changes skin files. You do not need to recompile to test it.

[mixxxbot]

Commented by: Be-ing
Date: 2018-04-01T18:55:02Z

---

This is just a guess, but maybe this only affected Macs without dedicated graphics cards (Intel Integrated Graphics only).

[mixxxbot]

Commented by: tildearrow
Date: 2018-04-04T23:09:39Z

---

Good news. Issue seems to not occur anymore.

[mixxxbot]

Commented by: Be-ing
Date: 2018-04-04T23:22:44Z

---

Great! Thank you for confirming.

[mixxxbot]

Issue closed with status Fix Released.