SUMMARY Latte-dock freezes for 1 or 2 seconds on various situations iff Visual Studio Code is open. STEPS TO REPRODUCE 1. Launch latte-dock. Everything works as expected. 2. Launch Visual Studio Code (tested with latest stable version, 1.41.0; also happened with the previous stable version). 3. Change to another virtual desktop. The dock will be frozen for one or two seconds. This also happens if you just simply click on any launcher on the dock. 4. If you close Visual Studio Code, latte-dock works again smoothly as expected. OBSERVED RESULT latte-dock freezes for one or two seconds in different situations iff Visual Studio Code is open. EXPECTED RESULT latte-dock not freezing even if Visual Studio Code is open. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Kubuntu 18.04 with KDE backports (available in About System) KDE Plasma Version: 5.12.9 KDE Frameworks Version: 5.47.0 Qt Version: 5.9.5 ADDITIONAL INFORMATION Launching latte-dock with the -d option provides this output when Visual Studio Code is launched: (code:5966): Gtk-WARNING **: 13:53:19.872: Theme parsing error: gtk.css:68:35: The style property GtkButton:child-displacement-x is deprecated and shouldn't be used anymore. It will be removed in a future version (code:5966): Gtk-WARNING **: 13:53:19.872: Theme parsing error: gtk.css:69:35: The style property GtkButton:child-displacement-y is deprecated and shouldn't be used anymore. It will be removed in a future version (code:5966): Gtk-WARNING **: 13:53:19.872: Theme parsing error: gtk.css:73:46: The style property GtkScrolledWindow:scrollbars-within-bevel is deprecated and shouldn't be used anymore. It will be removed in a future version Option 'sandbox' is unknown. Ignoring. [main 2019-12-18T12:53:20.168Z] update#setState idle [5991:1218/135320.313864:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command [5991:1218/135323.320826:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command [debug 13:53:28.104104] - SET FROZEN :: applications:code.desktop - 1.0111109020881694
1. Latte v0.8 is not the current stable version and is not getting any more updates 2. Use plasma panel and taskmanager, don't you have the same issue?
- I have updated latte-dock to testing with this PPA <https://launchpad.net/~rikmills/+archive/ubuntu/latte-dock> (after updating, version is 0.9.85) and the problem is still there. - Plank, Docky, the Icon-only task manager on a plasma panel and other Plasma launchers work normally. The only problematic configuration in my computer is Plank with Visual Studio Code.
(In reply to ruben.bejar from comment #2) > - I have updated latte-dock to testing with this PPA > <https://launchpad.net/~rikmills/+archive/ubuntu/latte-dock> (after > updating, version is 0.9.85) and the problem is still there. > - Plank, Docky, the Icon-only task manager on a plasma panel and other > Plasma launchers work normally. The only problematic configuration in my > computer is Plank with Visual Studio Code. I am sorry. Of course the last sentence should be "...in my computer, is Latte with Visual Studio Code"
(In reply to Michail Vourlakos from comment #1) > 1. Latte v0.8 is not the current stable version and is not getting any more > updates > 2. Use plasma panel and taskmanager, don't you have the same issue? - I have updated latte-dock to testing with this PPA <https://launchpad.net/~rikmills/+archive/ubuntu/latte-dock> (after updating, version is 0.9.85) and the problem is still there. - Plank, Docky, the Icon-only task manager on a plasma panel and other Plasma launchers work normally. The only problematic configuration in my computer is Plank with Visual Studio Code.
In such case I hope someone to find the issue then...
(In reply to ruben.bejar from comment #4) > (In reply to Michail Vourlakos from comment #1) > > 1. Latte v0.8 is not the current stable version and is not getting any more > > updates > > 2. Use plasma panel and taskmanager, don't you have the same issue? > > - I have updated latte-dock to testing with this PPA > <https://launchpad.net/~rikmills/+archive/ubuntu/latte-dock> (after > updating, version is 0.9.85) and the problem is still there. > - Plank, Docky, the Icon-only task manager on a plasma panel and other > Plasma launchers work normally. The only problematic configuration in my > computer is Plank with Visual Studio Code. Of course, the last sentence should be "The only problematic configuration in my computer is **Latte** with Visual Studio Code."
I am in openSUSE Tumbleweed and I installed VSCode with https://en.opensuse.org/Visual_Studio_Code I have opened a window VSCode without any project opened and I do not get any freezes OR constant cpu usage. When you get freezes, have you checked the cpu usage of Latte? If the Latte cpu usage is 0% then the issue is not with Latte.
I have recorded a couple of screencasts showing the task manager when latte and visual studio code are there. You can see the general behaviour, and that the CPU usage of latte seems to be high when the freezes happen. You can download them from my GDrive (you should not need to login to any Google account): https://drive.google.com/file/d/1Ypaqt9ucjuMyG4ax51jF9ku3VTNmXBpW/view?usp=sharing
how have you installed Visual Studio?
(In reply to Michail Vourlakos from comment #9) > how have you installed Visual Studio? As suggested [here](https://code.visualstudio.com/docs/setup/linux), I installed the .deb (with sudo dpkg -i). That installed [this repository](http://packages.microsoft.com/repos/vscode) in my system so now code, stable, updates automatically.
as a reference, this is a video how it behaves normally in my system: https://drive.google.com/file/d/1HRd9Uh-Pt_Y8cQgLBdz5xmHfGU-DJVxL/view as a guess, high cpu usage can occur when a specific application is continuously sending window changed events but this can be debugged only in the machine that this occurs. the window changed signaling for X11 is located at: https://phabricator.kde.org/source/latte-dock/browse/master/app/wm/xwindowinterface.cpp$628
this needs investigation at a machine that this issue appears...
I may try to replicate this behaviour in a Virtual Machine, trying to mimic my current configuration one step at a time until I nail it. If I can replicate it in a VM (VirtualBox is what I use), could you then take a look? It will take me some time and there is not any guarantee of success, so I need to know that it may be a really useful thing to do.
(In reply to ruben.bejar from comment #13) > I may try to replicate this behaviour in a Virtual Machine, trying to mimic > my current configuration one step at a time until I nail it. If I can > replicate it in a VM (VirtualBox is what I use), could you then take a look? > It will take me some time and there is not any guarantee of success, so I > need to know that it may be a really useful thing to do. probably not, too much of time in order to debug a corner case
to rephrase... If you manage to find concrete steps to reproduce the issue then I will take a look but I dont want to get into a process to install a new virtual machine, set it up etc etc...
OK. If i find a way to make it reproducible or somehow I find out some clues about possible causes I will add further comments to this issue. Thanks for your time!
Has been pointed as an electron issue