binned frame in GUI is not acceptable

[lbusoni]

The GUI is showing the frame obtained from getFrameForDisplay(), i.e. the last available frame (not necessarily a fresh one) and binned by 4. This is unacceptable for the alignment tasks typically performed with the GUI

The binning is needed to avoid the accumulation of delays in the GUI: although the reason is not totally clear to me, the symptom is a delay of several seconds (or minute) between the frame generation and the display on the GUI: the GUI keeps on displaying frames at a reasonable rate, but not the last ones. If you modify the exposure time, the GUI takes several seconds before the frames with the new intensity are shown, and the delay is apparently increasing.

The bottleneck is the frame transfer over the network between server and client, and apparently there is a buffer somewhere in some software layer (and some miscomprehension of zmq) that prevents a proper management of the frame reception.

The temporary (?) solution was to bin by 4 the frame published for the getFrameForDisplay. Is this really solving the issue? Probably no.

The idea was also that you don't need 2k by 2k frame for a fast display, as anyhow the GUI will be a few hundred pixels on the screen. But when you zoom into a smaller region you want to have it at full resolution

We should be capable of processing the last received frame, eventually dropping the old ones, not an old buffered frame.

Otherwise, we may have a frame published with just the pixels needed by the GUI, adding a complicated mechanism to keep track of which region is required by which client. But it looks ugly