On one of my machines, some Emacs commands are very slow when using the oxygen-gtk style. Examples for particularly slow emacs commands are delete-char, kill-word, scroll-down-line, scroll-up-line, and commands that open a new sub-window inside the Emacs frame. This makes this style nearly unusable with Emacs. I have tested this with Emacs 23.3, 24.1, and 24.3, the latter two compiled with GTK2 and GTK3, under KDE 4.8.4 and 4.9, with and without desktop effects, and under the i3 window manager, on openSUSE 12.2 and Fedora 17. The machine where this happens is an old laptop with an ATI Mobility FireGL T2 card (RV350 chip); it uses the radeon KMS driver. Reproducible: Always
Note that this problem is not related to the delays caused by some clipboard managers (see http://comments.gmane.org/gmane.emacs.help/80894/).
... definitly a -gtk2 engine issue (as far as I know) Have emacs 23.3.1 here and cannot reproduce ... (been typing and deleting keys and monitoring CPU usage, nothing happens ... No spike, no slowness. Do you have the same issue on more recent computers ? Other video cards ?
@Holger Might be some problem with driver or gtk. Would be good if you could use sysprof to find out where CPU time is spent on lags.
> ... definitly a -gtk2 engine issue (as far as I know) But it also happens with the gtk3 engine (emacs 24.x configured with --with-x-toolkit=gtk3). > Have emacs 23.3.1 here and cannot reproduce ... (been typing and deleting > keys and monitoring CPU usage, nothing happens ... No spike, no slowness. > Do you have the same issue on more recent computers ? Other video cards ? Performance is ok under openSUSE 12.2 running in a VirtualBox VM on a 2006 MacBook (CoreDuo 2, Intel video card). > Might be some problem with driver or gtk. Would be good if you could use > sysprof to find out where CPU time is spent on lags. Since performance was ok on openSUSE 12.1, the X server could also be the problem (both SUSE 12.2 and F17 use version 1.12). Strangely, other GTK applications do not feel slow. And I don't understand why the performance of an Emacs command like 'delete-char' can depend on the chosen GTK style (Adwaita, for example, is ok). I will try to profile this.
Just to give you an impression what I mean by "slow": When I load a file of a few hundred lines and then drag the scrollbar down quickly, it takes several seconds until the buffer displays the end of the file; I can literally watch it scroll down line by line.
Since, performance is better (though still too slow) when using the XRender backend instead of OpenGL, oxygen-gtk might also trigger a regression in Mesa. Is there something that the oxygen-gtk engine does fundamentally differently than other gtk engines?
Comparing the distribution of CPU time while constantly deleting characters in Emacs/GTK3/oxygen and Emacs/Motif, I get the following results: Emacs/GTK3/oxygen-gtk (slow): 60% Xorg 15-20% kworker/0:0 6% kwin 4% emacs Emacs/Motif (performance ok): 35% emacs 16% Xorg 14% kwin 0% (with occasional spikes to 20%) kworker/0:0
What is fundamentally different for oxygen-gtk from other engines is: 1. Much more complex render 2. Many hacks which might trigger extra repaints or something like
If have noticed another problem when using Emacs with oxygen-gtk: in the majority of cases, while keeping one or more keys pressed in Emacs, the X server is blocked by Emacs, i.e., no X window except the Emacs window is updated/redrawn until the keys are released. This does not happen for me with other GTK engines I have tried. I suspect this behavior could have something to do with this bug. Any ideas how oxygen-gtk could cause this?
Most likely a bug in some X component, e.g. video driver.
@Holger I agree with you that the issue you report in #9 is likely related. Most of the errors you report are indeed keyboard related, something with wich oxygen-gtk has nothing to do. We don't grab keyboard, trigger repaint on key press (although gtk internally does), etc. All in all I agree with Ruslan that this is likely due to some upstream component in your setup, and that we can't do much about it. Among the differences that we have with respect to other style, besides what Ruslan already quoted, there is: - the use of cairo - the larger amount of repaint events that we spawn (with respect to what gtk does), due to animations. Question: what happens if you turn off all animations in oxygen ? Does the situation improve ? If yes then I'd suggest you use this setup. If no, well, I have no clue ... In any case, closing as upstream since - none of the devs (Ruslan and I) can reproduce the issue - you cannot reproduce it on different upstream setups (X, drivers, etc.) Sorry, Hugo
> Question: what happens if you turn off all animations in oxygen ? Does the > situation improve ? If yes then I'd suggest you use this setup. If no, well, > I have no clue ... No, turning off animations doesn't help; no change. > Most of the errors you report are indeed keyboard related, something with > wich oxygen-gtk has nothing to do. We don't grab keyboard, trigger repaint > on key press (although gtk internally does), etc. Ok, but isn't it strange that other styles do not have this effect? I can't believe this is just because oxygen's drawing is a bit more expensive than that of other styles.
> Ok, but isn't it strange that other styles do not have this effect? I can't believe this is just because oxygen's drawing is a bit more expensive than that of other styles. It's not *just* because of expensiveness. Oxygen actively uses many cairo features which may uncover bugs in X drivers (and there also have been some visual glitches because of this).
... also (just a wild guess), can you try run after setting environment variable OXYGEN_DISABLE_INNER_SHADOWS_HACK to 1 (using either setenv or export depending on your shell) ? Does that improve things ? (maybe compositing does affect keyboard handling, you never know ...)
> ... also (just a wild guess), can you try run after setting environment > variable OXYGEN_DISABLE_INNER_SHADOWS_HACK to 1 (using either setenv or > export depending on your shell) ? Does that improve things ? (maybe > compositing does affect keyboard handling, you never know ...) No, setting this variable didn't improve things.
I got something: When I turn off the scrollbars in Emacs, the slowness goes away! Emacs obviously triggers many updates of the scrollbar and these seem to be very expensive, for whatever reason.
Btw., this problem is not restricted to Emacs; I can see it also with "normal" GTK apps. Scrolling text using the keyboard (which updates the scrollbar) in Gedit, for example, is much slower with oxygen-gtk than with Adwaita. > none of the devs (Ruslan and I) can reproduce the issue Maybe your machines are simply too fast to notice this...
> Maybe your machines are simply too fast to notice this... Maybe. In this case profiling done by you is the only way we could know what component leads to this.