Task #270

Task #351: Performance refactoring

Rebuild GUI refresh to base on Channel broadcasts instead of polling the channels

Added by Espen Solbu about 6 years ago. Updated over 5 years ago.

Status:RejectedStart date:01/19/2012
Priority:LowDue date:
Assignee:Espen Solbu% Done:

0%

Category:RefactorSpent time:-
Target version:2.5 Maintenance

Description

Eg. Upon model config/channel config or onResume:
- Build Channel List (listenfor id and view id) (or use local channel list)
- register listeners

In listener, update list

Cyclically, iterate the list, update the corresponding view IDs
onResume(){
localChannelList = currentModel.getChannels()

}

History

#1 Updated by Espen Solbu almost 6 years ago

  • Parent task set to #289

#2 Updated by Espen Solbu almost 6 years ago

  • Target version changed from 3.0 FrSky hub and sensors to 2.5 Maintenance
  • Parent task changed from #289 to #351

#3 Updated by Hans Cappelle almost 6 years ago

Do I get it that this is a proposition to change the GUI from checking the server on an interval towards server broadcasting and GUI listening? If so I agree.

In case the amount of updates is too high for several sensor values we could reduce traffic by putting only unique sensor ids together in a broadcast event. Collect in hashmap on server side and if key is found in map (=second value for this sensor) perform broadcast and empty map to be ready to accept next iteration of sensor values.

If I get this wrong maybe better to create another refactor task for this...

#4 Updated by Espen Solbu almost 6 years ago

Yes this is to stop GUI from checking server.
All channel updates are already broadcast, however we would slow down the gui if we update on all of them. I was thinking having the gui "catch" them all, but only update presentation on an interval.

We could add another single broadcast with all the channel values as you state, not sure if this is neccessary though..

#5 Updated by Hans Cappelle over 5 years ago

So like it now is implemented in the Hub activity? There I update the values on broadcast receive and then a runnable updates the gui with these values on given interval.

#6 Updated by Espen Solbu over 5 years ago

Yes, this to prevent the cyclic server poll.
not really an important refactor though, but would help to keep things ascynchronous.

(the runnable is already in the dashboard, just make it check the collection instead.)

However. it might be messy registering for all the active channels...
(need at least rssi channels as well as the model channels)

#7 Updated by Espen Solbu over 5 years ago

  • Status changed from New to Rejected

Broadcasts are slow, need to get away from broadcasts completely

Also available in: Atom PDF