During a recent workshop, one of the participants was using a 2018 MacBook Pro, 15" Retina (see screenshot). It uses a nice 6coreHT i7-8850H CPU at 2.6GHz base clock. We were very disappointed with DCP-o-matic's player performance, as even at quarter resolution decoding, it skipped very many frames. We disabled an antivirus software, but no change. I ran through BigBuckBunny to compare encoding speed with my older MacBook Pro, and the CPU/system itself is doing fine, 12.5fps during encoding, which is similar to what other 6coreHT CPUs yield. The machine is running Mojave/10.14. My personal non-retina 15" MacBook pro uses an older 4coreHT CPU, Sierra/10.12, and encodes BigBuckBunny at half the speed, yet playback performance in player is far better - it plays 25fps at half 2k decoding resolution without any skipped frames. I reduced the display resolution, because the Retina display has a very high resolution, and currently, DCP-o-matic player has a weak point in pushing the video to the display. That didn't solve the issue either (not the slightest bit). I noticed though, when I encoded BigBuckBunny, that DCP-o-matic wasn't even able to playback the preview of the original source video without stuttering. We tried both 2.12.20 and 2.13.132. I still believe this has something to do with the display addressing. The filmmaker of course is very disappointed because she paid quite a bunch of $ for this machine. Did anyone experience something similar on his machine? Unfortunately, there was only limited time during the workshop to analyze the issue, and I don't know anyone personally with a similar machine. Carl - you mentioned a prototype open-gl output module - could you make a beta version of the player available to see if that is an immediate improvement? I noticed something interesting on that machine - activity monitor shows only 6 of the 12 HT cores being active during playback in player. Usually, I would think that this would show a weakness with the multithreaded J2K decoder - however, if there is another bottleneck with the actual display process, that could as well mean that the J2K decoder is idling because the display process is too slow in asking for more frames? - Carsten