Open Searinox opened 2 years ago
Update: Tested more and corrected initial assumption in the first post(the new conclusion is even weirder).
The table doesn't even have to be selected, just being in tree view will do it.
Let me guess - you have automatic clearing of finished uploads enabled. The shared files tables needs to be updated every time a "new" upload starts in order for the value of the "Downloads" column to be correct. When finished uploads are not cleared automatically, only genuinely new uploads are considered to be "new" and updates are infrequent. Currently updates happen on a timer which fires once a second, and it only updates if the Library tab is visible.
I'll need to think of some more general approach to deciding which Upload request is "new". Maybe some sort of field which gets set in the core.
In build 98 the Library should be refreshed only on the first upload request over a given connection. This should fix the poor responsiveness. There is also a fix to the upload slot management which was broken because it only counted hash list uploads.
It's an improvement in how often it's happening, though ultimately the amount of time the UI freezes for depends on the size of one's share. The way you describe the issue I'm not sure what more can be done outside some extra data set that keeps track of what is where when a list is sorted. I'm not going to expect much more on this one since it seems like a tall order and I'll just leave it open for you to decide next.
I've been very lax at firing an event that all the data in the table has changed because it was the only way I knew how to trigger a table update. This is an opportunity to learn how to update individual tows which will come very handy in many other situations. So I'll leave this issue open and get busy reading the API docs :)
Alright, I have some code which I consider experimental in 98-2. Basically it updates only the rows of the table that would be affected by a new upload. Please test with various combination of filtering, sorting, etc.
I've seen uploads through sorting by name and download counts and it seemed fine. If someone hits me on search results - including by myself - will freeze up the entire UI with a timer consistent with the list sorting, no matter if I am or am not on the Library tab, or whether the Library is displaying in Tree or Table mode.
There is a problem with updating just the rows that have changed when you respond to a search result. For some reason it does not sort properly and I think this is a Swing bug. So I do a full-table sort but only if the table was sorted by the "Search Hits" column.
I put together 98-3 with the full table sort disabled so you can see for yourself what I mean by the sorting being broken. I have not committed the change to git yet though. https://muwire.com/downloads/MuWire-0.8.10-GitHub98-3.zip
So this problem happens whenever someone has a search hit on your files, including yourself.
I'm thinking one of the things you could do is:
If the Library Table View isn't in focus when a new hit/download comes in, save it in a to-update list that's structured like: if the file that was hit isn't in the to-update list, add it and increment the search hit or downloader count, if it already exists in the to-update list just increment its counts.
I'm not familiar with Java, does it support dictionaries? Could have a dictionary where the key is the file paths and the values are a structure containing the lists of downloaders, searchers, and total count.
And whenever the user tabs to the Library Table View list again, update the entries in the table with what is in the to-update list and empty the list.
And only update Library Table View directly if it's actually selected + we are in the Library tab.
The expensive operation is the re-sorting of the Table view, which happens only if the "hits" column had been sorted. If I delay the work as you suggest it would have to take place when switching to the Library view. Still that may be an improvement, so I'll take a look.
Having the Shared Files table view sorted by any column causes frequent loss of responsiveness in the UI while uploads are ongoing. This resolves as long as being tabbed away. This will happen and be very noticeable with as few as 1-2 simultaneous uploads. This is weird as uploads should not be refreshing the shared files table in any way.