Should the updater be part of an invokee?

[johannesugb]

The question arose if the updater shall not be a separate entity but instead, be part of class invokee.
There are advantages and disadvantages of either way.

Advantages of updater being part of invokee:

• Enabling and disabling of an invokee can be handled gracefully because the updater would only update if the invokee is active. However, the following question arises: What if 1) an invokee is disabled, 2) an event occurs (e.g. the swapchain is recreated), 3) the invokee is enabled => Shouldn't the updater update the invokee then, i.e. when it becomes enabled again?
• One can just use the already available std::optional<updater> and does not have to create a new one and add it to the composition.

Disadvantages of udpater being part of invokee:

• The memory footprint of an invokee grows. I think, the argument that an invokee is never a super-tiny class where it does not matter does not always hold true. What if an invokee represents some small entity, like 1000 bullets flying through the air. I think, it might make sense to use invokee with that, especially in combination with secondary command buffers and parallel invokers (see Issue Implement parallel_invoker #41). In that case, one would probably want to have the invokees as small as possible and not use an updater with them.
• The runtime costs grow by one additional if per invokee regardless of whether an updater is being used or not.

An alternative could maybe be to have another class updateable_invokee which is a (slightly) more heavyweight invokee as the original invokee, adding udpater support. But: how to call the updaters functionality without the above mentioned additional costs?

Think of the best strategy of solving this task and implement the solution!

Definition of done:

• One of the strategies described above (or a better one) is implemented w.r.t. updater <-> invokee integration
• No updater-methods are invoked if the updater is not used
• The 1) invokee disabling -> 2) event which triggers an update -> 3) invokee enabling situation is handled gracefully. The implementation does not have to be too complicated. Maybe even an unconditional update on enabling could be an option if the other options turn out to be too complicated.
• Can dependencies between different invokee's updaterss or between updater and invokee lead to specific problems? Can steps be taken to prevent such dependency-hazards? (Don't spend too much time on this since the updater is primarily a productivity-feature... but could also be relevant during regular usage - especially in swapchain recreation situations)
• Tests have been conducted that include enabling/disabling of invokees with associated updater
• Tests have been conducted that cover all currently implemented events
• Tests with multiple invokees and multiple updaters which are active at the same time have been conducted
• Both, debug and release modes have been tested
• The code is well documented and the Contribution Guidelines have been followed.