GUI doesn't want to draw until a cursor was not moved

pepsik · 2022-09-26 17:41:58

I remember time when all were ok, but after some update I met that problem.

Now every time when Im starting VSCode my applications do not want to draw, they wait for mouse movement, and than they starts to draw. So.. my applications literally say me "move your mouse to see something". I event dont see what Im typing until cursor wont be moved.

Not all of my applications have this issue, for example VSCode and xterm are continuing to draw things, but gnome-terminal, chromium, telegram are lagging.

I really don't have any clue what is going on. I thought it was because electron had started to use all of my cpu and somehow it was crossed with xorg, but several days later electron:8 updated to 9 and now it doesn't use so much cpu.
I'll be glad if I'll see any idea how to resolve this

Last edited by pepsik (2022-09-26 23:09:11)

seth · 2022-09-26 19:27:29

Do you use a compositor? Which?
Does it (in doubt try openbox w/o picom or xcompmgr) matter?

Please also revisit your OP and adjust the subject to be less generic.

V1del · 2022-09-26 19:29:20

Which graphics card/driver?

pepsik · 2022-09-26 22:59:29

1. Do you use a compositor? Which?
Yes, I use picom

2. Please also revisit your OP and adjust the subject to be less generic.
I want to, but which subject is more approach?

3. Which graphics card/driver?

laptop: thinkpad x1 9gen
graphics: intel-media-driver

I also read this hardware video acceleration, my chromium still is showing that my hardware acceleration is disabled though

Last edited by pepsik (2022-09-27 08:17:26)

V1del · 2022-09-27 05:57:44

Do you have xf86-video-intel installed? Remove it if so. As for picom, can you post it's config? Did you configure it to use the GLX rather than the xrender backend? Any specific custom config? As asked by seth, does disabling it have an effect on this issue?

pepsik · 2022-09-27 07:41:46

1. Do you have xf86-video-intel installed?
Yes I was using xf86-video-intel, removed it, we'll see what happen

2. As for picom, can you post it's config
picom.conf

# and Arch Wiki contributors: https://wiki.archlinux.org/index.php/Compton

#################################
#
# Backend
#
#################################

# Backend to use: "xrender" or "glx".
# GLX backend is typically much faster but depends on a sane driver.
backend = "glx";
# backend = "xrender"

#################################
#
# GLX backend
#
#################################

glx-no-stencil = true;

# GLX backend: Copy unmodified regions from front buffer instead of redrawing them all.
# My tests with nvidia-drivers show a 10% decrease in performance when the whole screen is modified,
# but a 20% increase when only 1/4 is.
# My tests on nouveau show terrible slowdown.
glx-copy-from-front = false;

# GLX backend: Use MESA_copy_sub_buffer to do partial screen update.
# My tests on nouveau shows a 200% performance boost when only 1/4 of the screen is updated.
# May break VSync and is not available on some drivers.
# Overrides --glx-copy-from-front.
# glx-use-copysubbuffermesa = true;

# GLX backend: Avoid rebinding pixmap on window damage.
# Probably could improve performance on rapid window content changes, but is known to break things on some drivers (LLVMpipe).
# Recommended if it works.
# glx-no-rebind-pixmap = true;

# GLX backend: GLX buffer swap method we assume.
# Could be undefined (0), copy (1), exchange (2), 3-6, or buffer-age (-1).
# undefined is the slowest and the safest, and the default value.
# copy is fastest, but may fail on some drivers,
# 2-6 are gradually slower but safer (6 is still faster than 0).
# Usually, double buffer means 2, triple buffer means 3.
# buffer-age means auto-detect using GLX_EXT_buffer_age, supported by some drivers.
# Useless with --glx-use-copysubbuffermesa.
# Partially breaks --resize-damage.
# Defaults to undefined.
#glx-swap-method = "undefined";

#################################
#
# Shadows
#
#################################

# Enabled client-side shadows on windows.
shadow = false;
# The blur radius for shadows. (default 12)
shadow-radius = 5;
# The left offset for shadows. (default -15)
shadow-offset-x = -5;
# The top offset for shadows. (default -15)
shadow-offset-y = -5;
# The translucency for shadows. (default .75)
shadow-opacity = 0.5;

log-level = "warn";
#change your username here
#log-file = "/home/erik/.config/compton.log";

# Set if you want different colour shadows
# shadow-red = 0.0;
# shadow-green = 0.0;
# shadow-blue = 0.0;

# The shadow exclude options are helpful if you have shadows enabled. Due to the way compton draws its shadows, certain applications will have visual glitches
# (most applications are fine, only apps that do weird things with xshapes or argb are affected).
# This list includes all the affected apps I found in my testing. The "! name~=''" part excludes shadows on any "Unknown" windows, this prevents a visual glitch with the XFWM alt tab switcher.
shadow-exclude = [
    "name = 'Notification'",
    "name = 'Plank'",
    "name = 'Docky'",
    "name = 'Kupfer'",
    "name = 'xfce4-notifyd'",
    "name *= 'VLC'",
    "name *= 'compton'",
    "name *= 'picom'",
    "name *= 'Chromium'",
    "name *= 'Chrome'",
    "class_g = 'Firefox' && argb",
    "class_g = 'Conky'",
    "class_g = 'Kupfer'",
    "class_g = 'Synapse'",
    "class_g ?= 'Notify-osd'",
    "class_g ?= 'Cairo-dock'",
    "class_g = 'Cairo-clock'",
    "class_g ?= 'Xfce4-notifyd'",
    "class_g ?= 'Xfce4-power-manager'",
    "_GTK_FRAME_EXTENTS@:c",
    "_NET_WM_STATE@:32a *= '_NET_WM_STATE_HIDDEN'"
];
# Avoid drawing shadow on all shaped windows (see also: --detect-rounded-corners)
shadow-ignore-shaped = false;

#################################
#
# Opacity
#
#################################

inactive-opacity = 1;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = false;

# Dim inactive windows. (0.0 - 1.0)
# inactive-dim = 0.2;
# Do not let dimness adjust based on window opacity.
# inactive-dim-fixed = true;
# Blur background of transparent windows. Bad performance with X Render backend. GLX backend is preferred.
# blur-background = true;
# Blur background of opaque windows with transparent frames as well.
# blur-background-frame = true;
# Do not let blur radius adjust based on window opacity.
blur-background-fixed = false;
blur-background-exclude = [
    "window_type = 'dock'",
    "window_type = 'desktop'",
    "_GTK_FRAME_EXTENTS@:c"
];

#################################
#
# Fading
#
#################################

# Fade windows during opacity changes.
fading = false;
# The time between steps in a fade in milliseconds. (default 10).
fade-delta = 4;
# Opacity change between steps while fading in. (default 0.028).
fade-in-step = 0.03;
# Opacity change between steps while fading out. (default 0.03).
fade-out-step = 0.03;
# Fade windows in/out when opening/closing
# no-fading-openclose = true;

# Specify a list of conditions of windows that should not be faded.
fade-exclude = [ ];

#################################
#
# Other
#
#################################

# Try to detect WM windows and mark them as active.
mark-wmwin-focused = true;
# Mark all non-WM but override-redirect windows active (e.g. menus).
mark-ovredir-focused = true;
# Use EWMH _NET_WM_ACTIVE_WINDOW to determine which window is focused instead of using FocusIn/Out events.
# Usually more reliable but depends on a EWMH-compliant WM.
use-ewmh-active-win = false;
# Detect rounded corners and treat them as rectangular when --shadow-ignore-shaped is on.
detect-rounded-corners = true;

# Detect _NET_WM_OPACITY on client windows, useful for window managers not passing _NET_WM_OPACITY of client windows to frame windows.
# This prevents opacity being ignored for some apps.
# For example without this enabled my xfce4-notifyd is 100% opacity no matter what.
detect-client-opacity = true;

# Specify refresh rate of the screen.
# If not specified or 0, picom will try detecting this with X RandR extension.
# refresh-rate = 0;

# Vertical synchronization: match the refresh rate of the monitor
# this breaks transparency in virtualbox - put a "#" before next line to fix that
# vsync = true;

# Enable DBE painting mode, intended to use with VSync to (hopefully) eliminate tearing.
# Reported to have no effect, though.
dbe = false;

# Limit picom to repaint at most once every 1 / refresh_rate second to boost performance.
# This should not be used with --vsync drm/opengl/opengl-oml as they essentially does --sw-opti's job already,
# unless you wish to specify a lower refresh rate than the actual value.
#sw-opti = true;

# Unredirect all windows if a full-screen opaque window is detected, to maximize performance for full-screen windows, like games.
# Known to cause flickering when redirecting/unredirecting windows.
unredir-if-possible = false;

# Specify a list of conditions of windows that should always be considered focused.
focus-exclude = [ ];

# Use WM_TRANSIENT_FOR to group windows, and consider windows in the same group focused at the same time.
detect-transient = true;
# Use WM_CLIENT_LEADER to group windows, and consider windows in the same group focused at the same time.
# WM_TRANSIENT_FOR has higher priority if --detect-transient is enabled, too.
detect-client-leader = true;

#################################
#
# Window type settings
#
#################################

wintypes:
{
  tooltip = { fade = true; shadow = true; opacity = 0.9; focus = true;};
  dock = { shadow = false; }
  dnd = { shadow = false; }
  popup_menu = { opacity = 0.9; }
  dropdown_menu = { opacity = 0.9; }
};

######################
#
# XSync
# See: https://github.com/yshui/compton/commit/b18d46bcbdc35a3b5620d817dd46fbc76485c20d
#
######################

# Use X Sync fence to sync clients' draw calls. Needed on nvidia-drivers with GLX backend for some users.
xrender-sync-fence = false;

3. Did you configure it to use the GLX rather than the xrender backend?
Yes

4. As asked by seth, does disabling it have an effect on this issue?
what is a seth?

seth · 2022-09-27 07:55:50

what is a seth?

https://en.wikipedia.org/wiki/Set_(deity)

Regardless of your heresy, "does disabling it have an effect on this issue"?

Edit: which kernel do you use and is the LTS kernel affected? (There're recent reports about "flicker" w/ the newer kernels that don't affect the LTS one)

Last edited by seth (2022-09-27 08:01:19)

pepsik · 2022-09-27 08:18:09

 Static hostname: thinkpad
       Icon name: computer
      Machine ID: d45d1ee2dd2a4619a1d7e024c49a9636
         Boot ID: 2d0e194141fd41609ec8640687e185e6
Operating System: Arch Linux                      
          Kernel: Linux 5.19.11-arch1-1
    Architecture: x86-64
 Hardware Vendor: Lenovo
  Hardware Model: ThinkPad X1 Carbon Gen 9
Firmware Version: N32ET79W (1.55 )

seth · 2022-09-27 08:33:08

seth wrote:

does disabling it have an effect on this issue […]
is the LTS kernel affected

pepsik · 2022-09-27 09:21:00

oh "seth" is you nickname, I didnt get it

Need to wait, this problem frequently occur but sometimes nothing happen and all are working as supposed to be.
And I didn't say that "draw freezing" will gone If restart the windows manager.
Sometimes it occur every single time when I'm starting VSCode, therefore I have to restart i3wm, but exist days when all work fine.

seth · 2022-09-27 13:12:50

And I didn't say that "draw freezing" will gone If restart the windows manager. Sometimes it occur every single time when I'm starting VSCode, therefore I have to restart i3wm

IOW restarting the WM (but likely also the display server) will fix the situation?
That's unfortunately not all that indicative.

The principle possible causes are (ignoring defective HW) the
- kernel module
- x11 driver
- compositor

You want to isolate the offending layer in order to address it, so you next want to change these things individually and trying to reproduce the problem.

Arch Linux

#1 2022-09-26 17:41:58

GUI doesn't want to draw until a cursor was not moved

#2 2022-09-26 19:27:29

Re: GUI doesn't want to draw until a cursor was not moved

#3 2022-09-26 19:29:20

Re: GUI doesn't want to draw until a cursor was not moved

#4 2022-09-26 22:59:29

Re: GUI doesn't want to draw until a cursor was not moved

#5 2022-09-27 05:57:44

Re: GUI doesn't want to draw until a cursor was not moved

#6 2022-09-27 07:41:46

Re: GUI doesn't want to draw until a cursor was not moved

#7 2022-09-27 07:55:50

Re: GUI doesn't want to draw until a cursor was not moved

#8 2022-09-27 08:18:09

Re: GUI doesn't want to draw until a cursor was not moved

#9 2022-09-27 08:33:08

Re: GUI doesn't want to draw until a cursor was not moved

#10 2022-09-27 09:21:00

Re: GUI doesn't want to draw until a cursor was not moved

#11 2022-09-27 13:12:50

Re: GUI doesn't want to draw until a cursor was not moved

Board footer