PF_AppGetColor() unsuitable for dynamic support of the new Light/Dark/Darkest Modes

The PF_AppGetColor() in PFAppSuite has never worked reliably in either After Effects and Premiere Pro, but this is more so of an issue now, with the introduction of Light / Dark / Darkest modes.

Here are the main issues with PF_AppGetColor & the SDK in general, when it comes to custom UI:

- The various constants in the header aren't documented, and while on first examination they are self-documenting, this isn't the case. For example, you might think that if your custom UI draws a button, it should use the color associated with PF_App_Color_BUTTON_FRAME for its border. But what happens if the button needs to be drawn disabled? There is no PF_App_Color_BUTTON_FRAME_DISABLED. But there is a 

PF_App_Color_FRAME_DISABLED. Is that what you’re supposed to use?

- No indication in the SDK as to the color space in which colors are returned. Are these sRGB? Or perhaps the color space of the main screen? What if the user has multiple screens with different color spaces? As for most  places in the SDK that deal with color samples, there is no recommendation. The only assumption our code can make is that the colors are provided in the color space of the main display, and similarly that the custom UI should be drawn in that color space. To the best of my knowledge our plug-ins do not know which native display the custom UI is going to be drawn on (at least on Mac).

- Even if you find a color that seems suitable for any given situation, the colors "dance around". Watch the attached video for an example, but it boils down to this: if you code a button to draw its border using the color returned by PF_App_Color_BUTTON_FRAME, you will notice that the SDK is returning wildly different values at each render pass. The video attached to this bug report shows that simply toggling one parameter’s visibility in quick succession, the button frame is drawn in black, orange or yellow:

Funny enough the color returned for those constants is the same for dark mode too:

So it's clearly not tied to the Appearance setting, and being influenced by some unknown graphics state.

- The above example shows another problem: the two buttons are drawn using PF_App_Color_BUTTON_TEXT and PF_App_Color_BUTTON_FRAME. Not only is the color returned for both constants identical, but it is also wrong. Look at how a native popup button is drawn by Premiere Pro in light mode:

The button fill should be close to white. The text and border should go from gray to darker gray if the mouse happens to be hovering over the control.

- ...and this brings us to the last problem with custom UI in Premiere Pro. The native UI uses plenty of color shifts to indicate that the mouse happens to be hovering above a control. But even if PF_AppGetColor were fixed, and color constants would return the correct values, these dynamic updates to control colors cannot be reliably implemented by third-party plugins. To correctly implement a mouse-hover effect, each custom UI area needs to have a perfect balance between mouse entered / mouse exited events. But this isn't true in either AE or Premiere Pro. The host app would have to guarantee that PF_Event_MOUSE_EXITED be always invoked when the cursor abandons a given custom UI area. But this event is only sent sporadically, if the mouse cursor is moved very slowly away from the parameter. If the user happens to be moving over the inspector quickly, a custom UI area will often get a series of other events, but not necessarily that last PF_Event_MOUSE_EXITED. This means that our custom UI could be left in a state where the UI is still drawn using the "highlight/hovering color" even when the mouse cursor is no longer above the custom UI. 

Spelled differently: the host app should assume that a prior DRAW may have occurred while the cursor was hovering above a button... and so a PF_Event_MOUSE_EXITED event followed by one more PF_Event_DRAW event are required for the custom UI to be drawn in the correct state (no more hover effects!)

I apologize for the long post... I'm a big fan of light/dark mode and this felt like a good time to point out the biggest obstacles that would allow third-party plugins to be first-class citizens in the inspector.