Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Locked Sluggish native panel response time compared to web
Recently I've spent some time comparing the web presentation (as shown in a web browser) for a layout editor panel, with that of the 'native' panel (that shown directly on the computer). What I noticed surprised me; the web panel was significantly more responsive than the native panel.
The native panel gives the impression of being 'polled', where sometimes it responds quickly, and other times there is a noticeable delay. I've not been able to actually measure the delays, but would put them all at sub-second, so these are by no means serious delays, but noticeable nevertheless! I'm just wondering if other people have noticed the effect and might know what is causing it. I've tried experimenting with browsers on the 'server' machine (i.e. where JMRI is running), on a separate machine and on a pretty old smartphone. I've had the server running on a cheap laptop and higher spec desktop and the effect is similar. In the case of the smartphone there was a slight delay in the browser response (but this corresponded in timing to a browser on the server machine), but the panel again lagged behind. The effects are similar whether the change is in response to a trigger from the browser or from the native panel itself. I'm not aware of this being a recent phenomenon, but for information I've tried it on the latest production release of 4.16 as well as the latest test (4.17.6) and development releases (4.17.7ish) and am not aware of a difference between them. From which I conclude it's not a recent effect, but cannot conclude how long it's been present. I've been doing my tests using a simple panel I created to demonstrate web differences: /g/jmriusers/files/ProblemsBeingWorkedOn/Andy%20Brown%20-%20161045/CrossoverBlockOccupancyIssue03.xml Desktop:
Andy |
Randall Wood
The rendering (and therefor visual responsiveness) of the native panel is performed in the Event Dispatch Thread (EDT) within JMRI (this is a hard requirement within Java). Because threading is very complex, JMRI also performs many other operations in the EDT. It appears to me that the GNOME (Ubuntu graphical application API) / Java interaction means that rendering is controlled by the EDT, but is on a GNOME-specific thread, which may mean that all EDT processing has to be completed and then the native interface updates smoothly (this implies that a macOS or Windows user may see different behavior than you do). Randall |
Randall
Thanks for the background - I should have know that this problem was above my pay grade! Based on your suggestion I ran Windows within VirtualBox (the nearest I have to a Windows machine) and installed v4.16 JMRI to do a comparison. As you say the response is different - the windows native panel offers a more immediate response. We're only talking fractions of a second here, but it is noticeable. This is even though it is operating as a VM within the same desktop machine. The VM is running:
Thanks for your help Andy |
to navigate to use esc to dismiss