No way to guarantee atomic updates of compositor layout

There's a fundamental problem with compositor and other elements like it where you can't update the properties on sink pads atomically, or guarantee when they'll be visible in the output stream.

That happens because the rendering is being done in a task on the source pad. When updating multiple sink pad properties, a new frame might be generated after only some are updated - resulting in a partially modified layout.

Even if the updates of all properties were atomic, that are also 2 cases to consider: Changes to the properties that should take effect immediately (on the next output buffer) and properties that should take effect on the next input buffer on that pad (reconfiguring due to a caps change, for example).

The GstController interface doesn't seem to offer a good way to handle this. I'm not sure if it could be extended to do so sensibly.

One option that would work (either in compositor, or in the aggregator base class):

• Add a draw/aggregate signal that is fired after collecting all input buffers to generate an output frame, but before doing the generating.
• Add a property on each sink pad that exposes a (read-only) GstSample that is created on demand when the property is read and which tells the consumer which input buffer, caps and segment are going to be used for the active render cycle.

In the callback for that signal, the consumer can update properties across all pads atomically before the rendering happens, and check (if needed) which buffer and caps will be used for rendering into this frame.