zlatinb / muwire

MuWire file sharing client for I2P
GNU General Public License v3.0
191 stars 27 forks source link

Poor responsiveness in Library tab when Uploading if Shared Files table sorted #98

Open Searinox opened 2 years ago

Searinox commented 2 years ago

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.

Searinox commented 2 years ago

Update: Tested more and corrected initial assumption in the first post(the new conclusion is even weirder).

Searinox commented 2 years ago

The table doesn't even have to be selected, just being in tree view will do it.

zlatinb commented 2 years ago

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.

zlatinb commented 2 years ago

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.

https://muwire.com/downloads/MuWire-0.8.10-GitHub98.zip

Searinox commented 2 years ago

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.

zlatinb commented 2 years ago

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 :)

zlatinb commented 2 years ago

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.

https://muwire.com/downloads/MuWire-0.8.10-GitHub98-2.zip

Searinox commented 2 years ago

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.

zlatinb commented 2 years ago

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

Searinox commented 2 years ago

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.

zlatinb commented 2 years ago

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.