I've changed style my Xubuntu 16.04, and that lag appears...
This is because of a bug in
gtk2-engines-murrine. It has been reported here.
sudo apt-get install gtk2-engines-murrine=0.98.2-0ubuntu2
To roll back version if you don't want to upgrade this package automatically use:
sudo echo "gtk2-engines-murrine hold" | sudo dpkg --set-selections
There's a better answer than downgrading a package. That's usually not a good idea, especially if there are simpler, higher-level ways of fixing a problem. Stuff like this is often fixed in future versions, and holding packages back - especially lower-level core packages - often creates dependency problems and unresolvable upgrade paths for other packages randomly in the future. (Well technically not "randomly" but seemingly so to end users.) Upgrading an entire distribution is an amazing feat, and I'm amazed it works every time - because upgrading everything by hand (on roll-your-own Linux) can be a never-ending nightmare that you eventually just refuse to do any more and stay frozen in time. Don't hamstring Canonical's ongoing hard work by holding packages back, if you can avoid it!
So here's a better, higher-level user-space solution:
In short, just run this one command:
xfconf-query -c xfce4-desktop -p /desktop-icons/center-text -n -t bool -s false
Some might argue that purposely creating an "incorrect" xconf setting to fix a visual bug is also a bad idea, and can also create problems in the future. I agree. But the fact is, there's a bug. Such is life with open-source. And as usual there are lots of workarounds. For example:
- You could easily just switch to another theme that doesn't use that engine and doesn't exhibit the bug.
- You could tweak your package management, potentially (probably) causing cascading dependency problems down the road later (when you may have forgotten what or why you did).
- You could tweak one xconf setting, "incorrectly", to fix the bug - potentially causing similar problems with that engine in the future if/when the authors fix the bug.
If it were me (and it was me because I had this problem too), I chose #3. The potential downside is real, but trivial. So imagine in the future, the bug is fixed, and our tweak brings the original - or a worse - visual bug back, and I forgot what tweak I made that needs to be un-done. Well, so what? At that point, I still have option #1 available. (Or find and undo #3 if I were really persistent.)
Option #2, at best, would just delay the problem. Because eventually, package dependency problems will force you to investigate why you're having upgrade problems, re-discover that you held a package back (probably forgetting why by then), and release the hold. Maybe the bug is fixed by then anyway, but maybe not and you're faced with #s 1 or 3 again.
Anyway, #2 was trivially easy, a single command, no sudo, and fixed the problem immediately. I love problems in Linux that have an easily Google-discovered, well-understood fix, and that is that simple! Good luck.