Re: [tauruslib-devel] Separation between widgets rendering and underlying event subescription

[Miquel N. <mna...@ce...>]

Hello Nicolas,

Sorry for the delay! I hope the Taurus training went well and was 
productive.

Regarding your inquiries, the answer is simple: the widget instantiation 
is, indeed, independent of the event subscription. You can even 
instantiate a Taurus widget without a device/attribute associated to it 
(although it will have no value). The subscription is triggered when 
associating the widget to device/attribute by calling the setModel 
method. This means that you could instantiate all widgets and set the 
models after the GUI rendered. However, if you are using the Taurus 
designer and set the model in the widget configuration, the setModel is 
called with the widget instantiation (to avoid it you could create the 
GUI with taurus designer but set the models by code after loading the 
.ui file).
In fact, Taurus already includes a feature that allows what you are 
asking for: the DelayedSubscriber. This feature lets you to set the 
models on the widget creation without triggering the subscription. 
Instead, it will enable polling for the attributes (so the widget will 
have values when the GUI opens) and then, it will gradually subscribe to 
the attributes in a background thread. We have been using this feature 
for a long time in some Control Room GUIs, however we tried to use it 
some months ago in a beamline and we had some problems (it was a test so 
we didn't investigate further).
Tell me if you need more details or you have any other question!

Changing the subject, in the last follow-up meeting you asked about what 
Tango community could change to help improving Taurus performance. The 
two features we thought when we started the Taurus Performance 
Optimization project are explained in the slides we presented at the 
Taurus Workshop in ESRF 
(https://indico.esrf.fr/event/76/contributions/389/attachments/225/463/TaurusWorkshopESRF_TaurusPerformance.pdf, 
slide 19). However, we don't want to officially ask for them until we 
know if there is room of improvement in the time performance of 
subscriptions with the current approach. Zibi already published the 
benchmarks in TangoTickets 
(https://gitlab.com/tango-controls/TangoTickets/-/issues/98). After we 
know if we could expect some improvements without adding extra 
features/parameters, we will evaluate if the changes are still worth the 
effort and formerly ask for the alternative approaches.

Thank you for your time and interest,
Miquel Navarro (on behalf of ALBA Controls)

On 2023-10-20 08:41, Nicolas Leclercq wrote:
> Hi Taurus experts,
>
> Following our discussion (during the last Taurus follow-up meeting) regarding the optimization of the event subscription mechanism in cppTango, I submitted to my kernel-mates the idea of making the underlying synchronous attribute reading optional. I’m now back with some questions for you guys.
>
> Does Taurus separate the widget instantiation from the associated event(s) subscription?
> In other words, does the widget instantiation trigger the event(s) subscription?
> Can the latter be postponed after the widget is rendered?
>
> The idea is obviously to have an « immediate » display of the main panel on screen while the subscriptions are being handled in the background.
>
> Thanks.
> Nicolas.
>
>
>
>
>
> _______________________________________________
> Tauruslib-devel mailing list
> Tau...@li...
> https://lists.sourceforge.net/lists/listinfo/tauruslib-devel