Proposal: Interactive Previews of Operations
As we develop geometric algorithms, it is becoming more important to show users the potential outcome of an operation visually. To do this interactively, there are several challenges:
Design Issues
- to maintain interactivity, generation of previews (which may take substantial time) should run in a background thread, not the GUI thread (so we prefer to make previews “launch-able” in the same way as the main operation);
- resource locking may prevent multiple previews from being simultaneously computed (and this can waste resources and prevent any previews in some cases), so there is a strong desire for cancel-able preview generation;
- there are several alternatives for where the preview geometry might live:
- on the input resource (but this would write-lock it during preview)
- on the input operation specification (but this would write-lock it during preview, preventing user editing of parameters during preview generation)
- on an attribute resource owned by the operation panel (this would require the operation’s preview method accept a “foreign” resource)
- the operation panel does not (and arguably should not) destroy parameters just because the user decides to abandon editing one operation temporarily in favor of another (which has implications for the paraview pipeline used to display previews);
- previews for different operations will need to control the display properties of their geometry and the operation-input’s geometry in different ways.
Proposed Design
- Add an
smtk::operation::Operation::preview(smtk::attribute::Resource::Ptr previewGeom)
method to the Operation class. Alternatively, we could alterOperation::operate()
to accept a preview attribute as input and addbool Operation::supportsPreviews()
so operations would not be required to generate previews. - Add a way for the operation launcher to
- cancel any running preview tasks for a given operation and
- invoke the
preview(...)
method, whose attribute resource will be passed to the launcher by the operation panel and will be write-locked.
- Make the operation panel create a pqPipelineResource for displaying preview geometry, attached to an attribute resource (call it PreviewResource) owned by the panel.
- Create an attribute in PreviewResource with items that the operation’s preview method can use to signal what components/resources should be hidden or rendered differently (say in wireframe mode) during preview.
- Hide PreviewResource when an operation is not being edited (i.e., when the operation is running or completed and no parameters have been changed; this is usually when the “Apply” button is disabled in the operation panel).
- Show the PreviewResource’s geometry (and adjust other pipeline object visibility) when a preview becomes available.
Discussion
This design should allow previews to be generated when it is computationally feasible while avoiding deadlocks in the GUI for large data. However, it does hinge on the ability of launchers to be able to cancel a preview operation. Otherwise, if a user clicked “Apply” while a long-running preview was being generated, the operation could not be run (due to the required write-lock on the input resources) until the preview completed.
This design should accommodate both operations that provide previews and those that do not (because they are difficult, or the operation does not have a visual component, or the operation’s effect is well-understood). Because the preview resource would be independent of the operation-specification’s native attribute resource, users could continue to adjust parameters in the GUI while a preview is being generated — although doing so would cancel the running preview and queue a new preview computation.