Does anyone have a clue as to what could be going on here? What even happens when repaint is called on a blank child component that could be causing slowdown? Is there overhead associated with drawing the section of the parent component over which it exists? Isn't that cached? This had no effect on the result and I still experienced the accumulating lag.
#PRO TOOLS 12 OSX EL CAPITAN CODE#
It's almost as if the OS is preventing our app from drawing more CPU in order to account for the frequent repaints.Īs a sanity check, going off of Jules' comments in similar threads suggesting simplifying the paint callback, I tried commenting out all code in our meters' paint function, so they were completely blank. Interestingly, the CPU of our program hardly even rises during this situation (totaling ~20%) so I have no idea what's causing the lag. If you let playback continue for 20 seconds or so, this delay becomes much longer (6 seconds, etc.) so it seems like the frequent calls to repaint are "piling up" and preventing the main thread from doing anything else until they are cleared. After the El Capitan update, it seems that something is happening where the repaint calls are "piling up" and causing our main thread to become unresponsive.įor instance if you start playback (meter values start changing and calling repaint) then try to hit the stop button, you'll get a small delay (1 second) from when the button is clicked and when it actually changes. In our case, we have a separate thread running at 60fps which looks for any changes made to our incoming metering values and calls repaint() on the meter whenever necessary. This only became an issue after the El Capitan update.
We're experiencing this on a desktop application (the Raven) and it also seems to be related to frequent calls being made to repaint for our meters. That will sound alarming but in my opinion here's the status right now: you can't use Juce drawing for any animation inside your plugin, unless you don't care about performance on El Capitan. Are you going to have one big OpenGL context for all of your GUI? You can forget about Juce::Component for your GUI component then. But what are you going to do if you have several part of your plugin that needs animations? And what if the animated place of your gui can move? Are you going to create several openGL context and move them around? that sounds inefficient. Right now the only way to go would be effectively to go OpenGL mode.
so I don't see how using a ChangeBroadcaster / ChangeListener would help me, because there is no message to coalesces, I'll still send ask for the same number of repaint per second. Let's keep the 30 FPS example (which is not a crazy framerate for an animation): I still want to have 30 repaint per second, so I need to ask for a repaint approximately every 33ms, and get it.
Optional Storage Drive (Hard Drive) - For the larger sound libraries, the traditional platter hard drive is a good choice as they are still much cheaper per GB than SSDs.I get that ChangeBroadcaster / ChangeListener can coalesces message, so it can be useful if we would ask for too much repaint than we effectively get / need, but that's not the case here. For traditional spindle hard drives, having your sessions and samples on separate drives can at times improve performance.
Optional Tertiary Drive - Samples (SSD/ Hard Drive) - The performance of one SSD can support both the sessions and samples. Secondary Drive - Sessions (SSD/Hard Drive) - If possible, it is a good idea to separate your project files and disk cache onto a secondary drive. An SSD is highly recommended as it will greatly improve how fast the OS and programs startup.
#PRO TOOLS 12 OSX EL CAPITAN PRO#
Primary Drive - OS/Software (SSD) - Includes your operating system, the base Pro Tools / Logic Pro installation, and your plug-ins. In general, we recommend a two to four hard drive configuration depending on your budget and desired performance level:
0 kommentar(er)
