"Antonio-M. Corbi Bellot" <antonio.co...@ua.es> wrote:

> I am currently using i3 version 4.10.2.
> Since a few months I've been observing a strange behaviour in i3 when I
> assign a window from emacs or chromium to a specific workspace. The
> behaviour I'm describing here was also the same with i3 4.[7,8,9].x.
> For example, I assign emacs to this key combination:
> bindsym $mod+Shift+m  exec "emacs"
> And the workspace assignment is this:
> assign [class="Emacs"] 2
> Assuming I'm working in workspace 1, when I press $mod+Shift+m (I don't
> change to ws 2 for the moment), emacs starts in workspace 2 but I see
> an increment in cpu usage being the main culprits emacs (approx. 60%
> cpu usage) and xorg (approx. 90% cpu usage). And this cpu usage is
> sustained...it doesn't slow down until I change to workspace 2 ($mod+2)
> and then I observe that emacs hasn't finished starting and in the very
> moment I've changed to workspace 2 it is like it resumes execution and
> it finishes starting normally. It is then that cpu usage from xorg and
> emacs slow down to their normal values.
> I've also observed this behaviour with chromium, no other applications
> suffer from this 'strange' behaviour, i.e I use claws-mail in workspace
> 4 and it opens there without a glitch. Also I use glade (3.18.1) in
> this way, assigned to workspace 2, and it starts nicely.
> I'm not sure if it is an emacs/chromium bug or an i3 bug or even a xorg
> bug, but I've observed it only with i3 and these applications.
> Has anyone observed this?

I've observed similar behaviour as a result of the i3 config line:

| exec --no-startup-id i3-msg 'workspace 4; exec emacs; workspace 1'

My workaround is to drop the "workspace 1", otherwise emacs busy-loops
on fd 6 (socket /tmp/.X11-unix/X0) until I switch to its workspace
and wait for the window to be rendered.

I don't use chromium (not enough RAM to build it).


Attachment: pgp8n8SlR_iAF.pgp
Description: OpenPGP digital signature

Reply via email to