Value handling, Threads
When receiving a new value from EPICS Channel Access
or whatever network protocol is used, one cannot
immediately update the screen with that value:
- The network library probably uses multiple threads,
yet Eclipse UI updates must only happen inside the UI thread.
- When many new values arrive, tbat can be too much
for the GUI.
Currently, each new value is handled as follows:
- ChannelAccess client library has unknown threads, further wrapped by
the PVTable's 'PV' interface (EPICS_V3_PV implementation).
- PVListModel receives PV value updates, and marks the associated entry
as "changed".
- Periodic PVListModelValueUpdateThread checks if any model entries
have changed, and notifies listeners.
This layer throttles the updates. Even if multiple value updates arrive for an
entry between checks, only one entry update is sent.
Up to here, it's all independent of Eclipse APIs
- The PVTableViewerHelper which interfaces the model with the SWT table
in the editor or viewer receives the updates.
It uses 'Display.syncExec' to run the table update in the UI thread.
Used 'syncExec' instead of 'asyn..' because the update thread should
wait for the updates to finish, not start new updates in case the current
screen redraw is too slow.
Advantage: Separation of network lib, model, UI.
Disadvantage: Too many layers, overall too slow?
- Original Performace: "Editor" table with 99 PVs at 10Hz used 70..75% CPU,
and didn't really update at 10Hz.
- Added hash map to resolve arriving PV monitors to the table entry:
No change.
- Separated PV model listeners to 'value' from the model 'structure' listeners,
so that table editor can only listen to 'structure' changes in order to
update the 'dirty' status, but ignore the value updates which are alread handled
by the PVTableViewerHelper: 60..70% CPU load, but still not 10Hz display updates.
- Enabled 'setUseHashlookup(true)' for the JFace table viewer
(which uses SWT.VIRTUAL with ILazyContentProvider): No visible change,
though mapping from model entry to associated SWT widget looks 'faster'
in the debugger.
One fundamental issue is the Eclipse Table and TableViewer.
In principle, it seems reasonable to only redraw the table cells
that actually change dynamically (time, PV, Readback).
But any attempts to redraw only those cells, or maybe only the changed
table rows turned out to be much slower than a full table refresh.