User Interface Processing Proposed
Standard version: 1.4
Minor Change
Gary at Genarts is looking for host that wants to implement to write example/better doc.
Note (by Pierre Jasmin): Gary from Genarts was saying this need to be changed. Not the proper way to do this.
Gary (2015-04-30): Consulting with the team here, I now think the API functions are OK, but need better documentation of what's supposed to be passed where and when. I'll work on an update. Need an interested host partner to implement. (Assimilate has a version but we've identified some issues that could use work.)
Some plug-ins perform heavy processing in response to UI interaction. This is typically some sort of analysis of images to shove into parameters to be used in a later render call. For example, a stabilisation plug-in might analyse all frames of an input clip for motion and write parameter keyframes representing that motion. During render, those values are fetched and used to stabilise the image.
This heavy weight processing can lock up the UI thread on many hosts, and can be distinctly user hostile. A way around this is needed, so that the plug-in can report to the host it is going to lock up processing, or even some way of batching that to a background thread.
This is a suite - Suite don't have the same insertion cycles as the rest.
This suite can be supported by any host that support 1.4 - There is a volunteer (Gary at Genarts) to support that. There has been a variation of this implemented by Assimilate and Genarts but it is an _EXT right now (not in shipping version).
(pierre): Gary, at NAB you discussed some dialog extention, I believe for when you popup your UI panel that you don't become hidden under the host UI… There was already a request (by Bruno, and we also had that problem) under User Interface Processing where if we popup a fancy panel to indicate what is going on to user during some analysis something similar can easily happen. That request right now has no specifications, maybe what you discussed you had to do with Gerk can be extended for that purpose as well…
(gary) Here is what we are using with Scratch now (minus some introductory comments etc.):
/** @file ofxDialog.h This file contains an optional suite which should be used to popup a native OS dialog from a host parameter changed action. When a host uses a fullscreen window and is running the OFX plugins in another thread it can lead to a lot of conflicts if that plugin will try to open its own window. This suite will provide the functionality for a plugin to request running its dialog in the UI thread, and informing the host it will do this so it can take the appropriate actions needed. (Like lowering its priority etc..) */ /** @brief The name of the Dialog suite, used to fetch from a host via OfxHost::fetchSuite */ #define kOfxDialogSuite "OfxDialogSuite" /** @brief Action called after a dialog has requested a 'Dialog' The arguments to the action are: \arg user_data - Pointer which was provided when the plugin requested the Dialog When the plugin receives this action it is safe to popup a dialog. It runs in the host's UI thread, which may differ from the main OFX processing thread. Plugin should return from this action when all Dialog interactions are done. At that point the host will continue again. The host will not send any other messages asynchronous to this one. */ #define kOfxActionDialog "OfxActionDialog" typedef struct OfxDialogSuiteV1 { /** @brief Request the host to send a kOfxActionDialog to the plugin from its UI thread. \pre - user_data: A pointer to any user data \post @returns - ::kOfxStatOK - The host has queued the request and will send an 'OfxActionDialog' - ::kOfxStatFailed - The host has no provisio for this or can not deal with it currently. */ OfxStatus (*RequestDialog)( void *user_data ); /** @brief Inform the host of redraw event so it can redraw itself If the host runs fullscreen in OpenGL, it would otherwise not receive redraw event when a dialog in front would catch all events. \pre \post @returns - ::kOfxStatReplyDefault */ OfxStatus (*NotifyRedrawPending)( void ); } OfxDialogSuiteV1;(pierre): I think that will do for us. One of our application is popping a dialog when analyzing long sequences to store data (store stuff in memory or in parameters), and our dialog includes things like Stop and Progress reports (stats…). What we have seen in this universe doing things like that is sometimes moving the mouse outside the popup dialog brings the host back in focus, can move the dialog under the host UI out of user sight…
(dennis): We do exactly this kind of blocking analysis in our Stabilize plug-in, but we use the OfxProgressSuite to report percentage done and monitor the Cancel button. Works great for that. How is this different?
(pierre): It's probably not in the way you use it then the my example. But there is no popup dialog in OFX and we have seen elsewhere that it's easy for a user to push the dialog under the app.