Help and Support
Ask a question, report a problem, request a feature...
<<  Back To Forum

Dragging Tixati Window Laggy / Bug

by Guest on 2020/11/16 10:00:20 PM    
When I drag around the Tixati window and my mouse polling rate is >=500 it will be very slow and laggy, putting the mouse polling rate in my control panel to 250 or lower fixes this. I've had this problem with other applications before (CPU-Z), but it seems newer versions fixed this.
I hope this can also be fixed for Tixati
by Guest on 2020/12/08 03:29:43 PM    
Just wanted to note it is still present in 2.77.
Here's a quick video I made of it, it's hard to show it without moving the mouse yourself, I hope you get what I mean.

https://streamable.com/ntd00i
by Guest on 2020/12/13 01:07:02 AM    
Same issue here. I just started using Tixati today, though. I have never seen this problem in another program. Only happens when trying to drag the window. Otherwise everything works.
by janet on 2020/12/13 04:21:37 AM    
This is a reply from KH on a similar thread:

by KH on 2020/12/08 01:37:33 AM    

We'll get this one next time, come hell or high water.

A cheap gaming mouse with high update rate will be arriving soon, then I will be able to re-create and solve it with some luck.
by Guest on 2021/05/10 09:17:48 PM    
Sorry to necro but did anyone get a fix? This seems to be a problem even in the newest version :/
by Guest on 2021/05/14 10:53:22 PM    
We haven't heard news. This is mainly a Windows problem that's made worse by a slow CPU and a high polling rate mouse just brings it to light. Check out the other thread if you want to read on details of what I paraphrased here.
by Guest on 2021/05/21 04:22:43 PM    
The simple answer is that Tixati needs rewriting with a separate thread for the interface. Back in the day I used to write assembler software, and it was best practice to assign a thread JUST for the interface, that could run concurrently with whatever processing the software was doing. That way the interface NEVER lags or stops responding when the processing thread is overloaded or waiting on disk responses.

Tixati is hamstrung sometimes by the fact that it's very disk-intensive. Using slower spinning disks, where there are lots of torrents or requests, and especially when doing BIG operations like verifying downloads or creating the full file images on a torrent start, it slows to a crawl waiting for the disk to respond, and since that thread is ALSO doing the interface response, it just hangs waiting for disk operations to complete. That's poor software design, I'm afraid. It may be that it's also not doing async disk operations, which is the best API for disk writes that releases control to the OS until the write is complete, so it can work on other things until the OS responds that the write is finished. The improvement from that to overall speed of any disk-intensive software is substantial.

I've also written elsewhere on this forum that there's a MAJOR stupidity in the way incoming data writes are processed, all coming into a SINGLE disk cache location and then each individual completed piece being copied from there into the correct location in the fileset. This means Tixati is doing TWICE the disk writing it needs to, as it's easy to write the data into the output file directly without this separate construction elsewhere, so it's highly inefficient. It also means that nearly complete pieces are useless to the downloader, when if they are contructed in situ inside the output file a 99% complete piece will present just a tiny glitch to a video player, rather than a piece-sized hole that'll never be filled as Tixati won't write incomplete data. AND allowing incoming data to write direct into the output files, which may be on multiple user disks, means the TOTAL disk bandwidth of Tixati increases substantially instead of being constrained by the bandwidth of that single cache disk, which is a bottleneck. And don't forget, if that cache disk is an SSD, then all the tiny writes Tixati does saving pieces and completion data is going to kill it VERY fast, even if it reduces the bandwidth bottleneck. So concentrating ALL incoming data writes into a single cache disk is VERY dumb on many levels.

I wish they'd fix these glaring issues in the file subsystem. No doubt the program is very effective now on the Bittorent side, but it could be far more efficient by doing far less IO, and this would directly improve the interface response even if they can't implement a thread just to handle that, which would eliminate lag completely.
by Owyn on 2021/11/21 06:31:06 PM    
Just wanted to note it is still present in 2.86-1.




This web site is powered by Super Simple Server