Are there harms of broadcasts of continuously updated data through multiple levels?

[Nokaroa]

I have HALs for a camera as well as a couple of encoders. I want the UI to have a live display of the view from the camera as well as a live display of the values from the encoders. All hardware modules are launched by the "Model" module, and the "View" module with the GUI is probably going to be in a higher level than the Model module. I could do all of this through subpanels, but then I don't have access to the data in the GUI module, and in the case of the camera view, there are things related to overlays which I would like to be able to do directly on the image data. I also have issues with scaling images through subpanels, but perhaps that's something more fixable.

What I could do is have camera broadcast "image data updated" every frame, have a helper loop in the model that rebroadcasts that same data, and have model's caller listen for that broadcast in its own helper loop and pass that data down to the view module. This seems like a lot of passing the same data around 30+ times per second through broadcasts from multiple modules. Is this a performance concern? Is there a commonly accepted way of solving this problem?   

[Ozfarmboy]

Two thoughts:

1. I prefer to keep all my imaging ac/proc/display in the one module, and then just broadcast the calculated data

2. If you do need to broadcast the images to elsewhere, remember you are only broadcasting a pointer to the image, not the entire image contents.

[Nokaroa]

I do need to broadcast the images. For the sake of code reuse, I am keeping my image processing separate from the capture module as the imaging is the same between applications, but the processing might be vastly different.

As far as broadcasting the pointer, I am less concerned about that and more concerned about the 30+ events per second that will be sent through multiple layers of the software. I can do it in an atomic way where it won't interfere with anything, but it still feels wrong having something so frequent going through the event handler loop

[joerg.hampel]

Off the top of my head, I would also suggest going with references or DVRs, and sending them directly to a dedicated helper loop for each consuming module ("point-to-point"). 

Similar to what we discussed in another thread recently, you can avoid static coupling between modules if you create the event registration for each module from it's own copy of the original broadcast typedef, and then share the broadcast references only at runtime:

Now, as for your question about dependencies. "If A gets the event registration references from B and passes them to C, that seems to break encapsulation for me?" - it does not if you are very clear about not reusing the typedef file from B but recreating another typedef file of the same datatype in C. That way, you can have that kind of dynamic event registration without a static linkage between B and C.

---

[Ozfarmboy]

---

@Nokaroa wrote:

I do need to broadcast the images. For the sake of code reuse, I am keeping my image processing separate from the capture module as the imaging is the same between applications, but the processing might be vastly different.

My approach might differ from others here on this forum, but I tend to favour fit for purpose over reuseable.  For example, instead of having a generic Image Acq module and then a specific Image Proc module, I sacrifice the reusability of the modules to have these merged into one module and hence be quite specific to the project.  If I get another project that requires Image Acq/Proc, I'll either start from this module, and quite possibly have to butcher it a fair bit to make it work for the next project, OR simply start again and use the previous project as a reference, OR make a basic template Image Acq/Proc module that we can use as a starting point.  But I would prefer to do this because I think it is better for the project, and I favour this over reusability.  

Where my code is reuseable, is that I have a Img Acq class that is called by the aforementioned DQMH module that uses inheritance to handle a number of different camera types, including a "simulator" camera which reads in images from a file.  This is where I make my code generic/reuseable. 

But I have found that the DQMH module is better to be fit for purpose rather than generic.  Otherwise you're spending a lot of time trying to write a theoretically perfect application that may not be all that practical.

[Nokaroa]

---

@Ozfarmboy wrote:
But I have found that the DQMH module is better to be fit for purpose rather than generic.  Otherwise you're spending a lot of time trying to write a theoretically perfect application that may not be all that practical.

---

This is a legitimate fear that I have. But so many of my applications are nearly identical in terms of acq and motor control and the only difference is going to be image processing/test. I like the idea of using inheritance for different cameras. I work for a camera vendor though and we've got so many cameras that chances are every testbed might be used for different cameras.