FrSkyRC / ETHOS-Feedback-Community

Feedback & suggestions are welcomed here for ETHOS by FrSky
191 stars 85 forks source link

widget lua only run when it is in active screen #2555

Closed Benno00 closed 1 year ago

Benno00 commented 1 year ago

Hello Bertrand, is there a way to stop lua scripts and only run them when the screen is active? I noticed that all Lua widgets are always started immediately when the transmitter is switched on, although the corresponding widget screen is not active at all, since Lua is then running in the background. Wouldn't it make sense to give luas a way to run these only when they are currently displayed, this should save resources and reduce memory requirements.

Greetings Benno

strgaltdel commented 1 year ago

Hi Benno.

' I noticed that all Lua widgets are always started immediately when the transmitter is switched on' i guess you're not right. at least my experience is a little bit another one (tested moons ago, so it may have changed)

1.) During boot, only init / create handler of all widgets are "one time" executed, NOT the whole widget ! (which, of course, results in mem consumption too)

2.) wakeup handler of a widget is called periodically, IN CASE THE CORRESPONDING WIDGET IS CONFIGURED IN THE MODEL. This handler is called independent of the status quo: it runs

3.) paint handler is ONLY called / executed, when the corresponding widget is configured on the active page. it doesn't run in case you entered another widget page or sys/model Config.

All in all, maybe that's what you meant and what i would support, if there would be one more handler which (like paint handler but with"functionality" of wakeup) is only called when the "widget page" is active,

so we would have "wakeup" as a background handler "foreground" as the mentioned handler, only active when widget page was selected and paint handler for screen refresh.

BUT .. and this is a big "BUT" i wouldn't support this in case it would increase (much) more refresh time of handler calls.

I experienced some sort of "performance issues" some weeks ago and examined:

in result the "refresh period" of the scripts grow dramatically (more than half a second) even in case the net runtime was less then 0.3 Secs in sum i got refresh rates of about 0.6 seconds, which causes "uncomfortable" user feedback on touch events or "press button"-triggered functions controlled by lua

I would assume there is a "sort of quota" for luas to guarantee the internal processing of the model control. The refresh rate was dependent on the model complexity, when i'm remembering right, a very simple model was able to reduce refresh rate by 0.15 seconds....

I never got those experiences on oTx, but to be fair, we 've hardware which delivers let's say 30 percent more performance then a X12, but in my case i was "pushing" by creating a config which was as double complex then on oTx, so at the end it was clear there must be a trade off (-;

All i want to say is, "we" should be careful with "extension ideas" and should have an eye on the overall performance. Ethos is much more capable then oTx, but we have to keep in mind there are physical limits ...

regards

Udo

Benno00 commented 1 year ago

Hello Udo,

Yes, you are right, I probably didn't express myself correctly. Each LUA is started once when switched on, if it is stored as a widget for the model, it is also started. Yes, Paint runs once when the widget is active Yes, wakeup is carried out if it is stored for the model and repeated approx. every 500ms, but unfortunately also if the widget does not have the active screen, i.e. in the background. Since I query the switches and pots with a lua swmap, I only need the wakeup as long as the weidget has the active screen. Then it can rest until it has the active screen again. The current side effect is when the lua runs as an inactive widget in the background or in the foreground, and you e.g. wants to change the model, e.g. the model images are displayed extremely slowly. If the wakeup is not executed in the lua, these model images are displayed significantly faster. And yes you are right that we should be careful with expansion ideas. Unfortunately I haven't found a solution for the swmap yet, how I could let the lua rest. But maybe you have a possibility to end the wakeup as long as the widget doesn't have the active screen? It would be enough for me if wakeup is not executed as long as the widget does not have the current screen.

Greetings Benno

bsongis-frsky commented 1 year ago

Perhaps just add a method so you can exit from wakeup() very quickly if the widget is not visible on screen

Benno00 commented 1 year ago

Hello Bertrand, thanks for the tip, but how is that supposed to work, do you have an example

With kind regards Benno

bsongis-frsky commented 1 year ago

Look at the gauge widget, here is the wakeup function, you could improve it by checking if the widget is visible on screen, like this:

local function wakeup(widget)
    if not lcd.isVisible() then
        return
    endif
    if widget.source then
        local newValue = widget.source:value()
        if widget.value ~= newValue then
            widget.value = newValue
            lcd.invalidate()
        end
    end
end
Benno00 commented 1 year ago

Hello Bertrand, that does not work! isVisible doesn't seem to exist. Thanks anyway. The error isVisible' is not callabl is reported error: /scripts/swmap/main.lua:1122: field 'isVisible' is not callable (a nil value)←[0m

1121 local function wakeup(widget) 1122 if not lcd.isVisible() then 1123 return 1124 end 1125 lcd.invalidate() 1126 end

But I found out that "local function paint(widget)" is not called if the widget is not visible on the screen that helps me. Thanks very much

Greetings Benno

bsongis-frsky commented 1 year ago

I have set the 1.5.0 milestone!

Benno00 commented 1 year ago

Hello Bertrand, Thank you, it's always nice how quickly you respond Thank you very much With kind regards Benno