aclist
[FEAT] Add a sortable ping column to server list
Device type
Desktop PC
DZGUI version
5.8.0
Linux distribution
Fedora
Describe the feature
User story
As a user who doesn't exactly know which server to play on, I'd like to sort the server table by ping so that I can find a server near my location
Acceptance Criteria
Any server list table, filtered or otherwise, can be sorted by ping in ascending or descending order.
Describe the benefit
I can make a more informed decision on which server to join
Thanks for the suggestion. I had gone back and forth on this several times during the course of development because the architecture that was in place at the time wasn't conducive to it, so what you see now (a statusbar update when you select a row) was a concession to keeping things performant without having to ping tens of thousands of servers while loading the data. Obviously, users didn't love this, and just wanted a list of pings by any means possible.
However, there is a major release (6.0.0) forthcoming in the next 48 hours on the Testing branch that overhauls many of DZGUI's core systems and adds a more robust threading and caching mechanism to take advantage of more of your CPU's cores. It's going to be significantly faster to load and interact with all server tables in this new release.
While a new ping system is not coming in that release, the new API in place could make this possible, so maybe it's time to revisit this feature.
Essentially, everything you see in the table is grabbed in one gulp, so while users expected to just automatically have ping data there, it's not something that's present from the get-go. We have to perform a round-trip to each server and actually test it to bring this data back and put it in place. You can see how this would start to add up depending on the combination of filters you have enabled (for example, if you have the most permissive filters and are showing every type of server, it can quickly add up to 40,000+ servers).
I've done a small test right now with the new multi-threading system, and I was able to get many thousands of results in a matter of seconds, so we have a couple of options here:
- Just do a one-time pass of all the servers and defer loading into the table until finished, albeit making the user wait a little bit longer. On the upside, in 6.0.0, loading the table itself is 200-300% faster than before, so maybe we can make use of this time savings to add the extra ping routine.
- Load into the table immediately and start pinging servers in the background while updating the results on the fly on a separate thread. This may not be ideal because:
- GTK is not thread-safe, so we have to take a lot of extra precautions to make sure the UI doesn't go haywire here.
- It may wreak havoc with the ascending/descending sort algorithm if the user is trying to click columns while they are being updated, with rows being moved in and out of place as they change.
I think in practice, most people aren't loading into the table with all 40,000 servers displayed, so it should be pretty responsive to frontload this in most cases.
On a low-spec PC, pinging all 40K servers upfront added about 45 seconds. On the other hand, the new server table only takes about 3 seconds to load.
If the user is willing to wait 45 seconds upfront, we could also make it an optional setting.
I'm thinking about other options.
A third option presents itself: load into the table immediately and then provide the user with an option to ping all servers and update their contents.
This won't keep users who don't need this feature waiting an unnecessary amount of time, and won't make the initial load-in feel extraneously long.
If a user isn't satisfied with checking ping on a row-by-row basis, they can then choose the "update all" option and wait for the results to repopulate.
What do you think about this?
I now have a prototype going for this and it should be fairly performant in most normal use cases. It's stable enough for inclusion in the 6.0.0 prerelease, so I'll be including it with some caveats.
I've added this feature to the Testing branch now. Thanks for spurring this change. After some stress-testing, it will enter the Stable branch. You can toggle branches in-app via Options > Toggle branch.
First, when loading into your Saved Servers and Recent Servers, the ping column is included by default and results will be shown automatically.
When loading into the Server Browser, the ping column is suppressed as a convenience to those who just want to load the results immediately. If you need a ping column after that, click the "Ping servers" button on the right panel to update the ping count in-place. Servers that were unreachable or timed out will be listed with a ping of 9999.
To prevent abuse, this button is usable once per filter context. For example, if you filter servers down and no new data had to be shown, the ping button is grayed out. If you choose a filter combination that leads to more servers being shown than were in the original results, the ping button is available again, and can be used to refresh the results.
You should use the ping more as a baseline of distance/performance. It is not something you need to constantly update. In conjunction with the real-world distance calculation in the statusbar, this should give you all the info you need to make an informed decision on a server.