Background and Solution Outline
This is a bit long, but the point is to educate via the Detailed Instructions section. If you're already educated, just read this section and possibly the conclusion ;-)
I have been using Synergy on Linux and Windows in its various forms since the 1990s, and this question pops up often. There are two common causes, and I deal here with the first only.
It's generally an OS-level issue, being the scheduler priority of the client, so the solution is simply to increase the client's priority. That will improve matters, but the overall experience will still be based on the scheduler's views on how important it is to update the screen, etc. See at the end for more on that.
Sometimes there is another reason: one or both of the server or client processes dies and gets restarted, in which case you should enable debug level logging on Synergy server and client, and take it from there. Once you're resolved that, implement the above.
Increasing Windows client scheduler priority
Using Windows 7, I don't know the short-cuts in newer versions.
Open the Task Manager (Ctrl-Alt-Esc) and click on the Processes tab.
Right-click on synergy.exe, click "Set Priority", and choose either High or Realtime.
Repeat for synergyc.exe.
If Synergy server is too slow, its process is synergys.exe.
Increasing Linux client scheduler priority
Something similar should work on Mac. You might know how to do this in the GUI, but I use the command line. Unless you do the following as root (
sudo su -), you'll have to play around (as root) with
visudo and set up the relevant rights to use
ps -eo pid,ni,cmd |\
grep synergy |\
grep -v grep |\
cut -d" " -f2 |\
while read pid; do echo -n $pid" "; done |\
xargs renice -19
You can copy & paste the above, or put it on one line by removing all the
\ and line break characters. If you want to see what will be run without actually doing it, change the last command to
xargs echo renice -19.
As stated above, this is still at the behest of the scheduler's view on the importance of lots of other processes. If you want to learn a bit, you can do the following.
Seeing Windows processes
Open the Task Manager. In the Processes tab, click on the button "Show processes from all users". Then click on the View menu, and on "Select Columns...". Make sure only the following are ticked: User Name, CPU Usage, CPU Time, Base Priority, Command Line. You can click on Description as well if you'd like.
You can drag the window as well as columns larger to ease reading. Click on a column header to sort by it. You can also right-click on an image name and, for example, go to the associated services. This is useful for such bland image names as svchost.exe. If you want a really powerful tool to play with (be careful!), try ProcessHacker.
Seeing Linux processes
ps -eo pid,ni,cmd | less to see all running processes. Each line represents a process status, and the columns are: the process ID, its priority, and the command-line in question. A gotcha is that in Unix, the lower the nice value, the higher the priority.
The thing is that Synergy depends on a whole lot of other processes to do part of its work (such as dealing with the SSL in Pro), and each of these processes has a priority assigned to it by the OS scheduler. Thus there really is no simple solution.
Even after applying the "fix" referred to above, things are often slow after entering a client screen where you haven't been for a while, and that is due to this whole family of processes being put on the scheduler's back burner, so to speak. Most schedulers these days are adaptive, and decrease the priority of user processes which have been idle for some time. For the scheduler to see them as important again requires continued use for a while, such as moving the mouse around a lot after you enter the screen. It's a pain, but that's how OS schedulers work in non-real-time operating systems.
There are ways to tweak that, but it's very specific to each OS (even different releases), and fragile (read: breaks easily upon OS patches). Without looking at the code, I expect Nick & team would only really solve this by pushing Synergy down to kernel driver level, which would make it way more fragile, and cause a significant price jump.