Bug 102295 - Shading an emacs window causes X to consume a lot of CPU
Summary: Shading an emacs window causes X to consume a lot of CPU
Status: RESOLVED NOT A BUG
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-23 18:05 UTC by Christopher Neufeld
Modified: 2005-06-07 20:27 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Neufeld 2005-03-23 18:05:59 UTC 
Version:            (using KDE KDE 3.4.0)
Installed from:    Compiled From Sources
Compiler:          gcc 3.4.3 Compiler compiled from sources
OS:                Linux

I create an emacs window by clicking a panel button that executes the command:
emacs -font 7x13 -geometry 80x70 %f

This window acts normally, until I shade it by double-clicking on the title bar.  At that point, the window shades, but there is a fast flickering of the single-pixel height region between the title bar and the grab bar that has been pulled up to meet it.  My X server CPU load jumps to about 50% of my Thunderbird 1100.

If I unshade the window by double-clicking on the title bar again, it does not restore its former 80x70 geometry, but gives me an emacs window with an edit region only one line high.  The CPU load due to X remains high.  If I resize this emacs window with the bottom grab bar, the resize works as expected, and the CPU load drops back down to normal levels.
Comment 1 Thiago Macieira 2005-03-24 02:23:04 UTC 
I can confirm this. Just open emacs and shade the window.

Emacs 21.3.1
X.org X11 R6.8.2
KDE 3.4.0 branch 20050313

Seli: is there to be done in kwin to prevent this? Or is this a fault in Emacs?
Comment 2 Lubos Lunak 2005-03-25 12:41:17 UTC 
It seems emacs tries to fight the geometry set by KWin. The geometry seems to fulfill emacs' size requests in WM_NORMAL_HINTS. Emacs most probably gets confused by the shaded frame geometry or something similar. Please report to emacs developers.
Comment 3 Christopher Neufeld 2005-04-18 03:22:26 UTC 
I'd just like to add that emacs isn't the only victim of this.  "xv" behaves in exactly the same way, and also returns from a shaded state into an incorrect geometry.  A kopete chat window which is shaded does not return to its original size when unshaded, but doesn't chew the CPU while shaded, so it might not be the same effect.

This didn't happen before 3.4.0.  

I'm not suggesting that we should reopen the bug, I just want to document this in case somebody does a bug search for "xv" or something, and files a new bug for the same thing.
Comment 4 Andreas Pakulat 2005-06-07 20:27:16 UTC 
Hi,

I'd like to say that this bug affects _all_ windows, as said in Bug 96602. So this bug needs to be reopend and properly addressed. Especially as there is no other related bug, I'm surprised that there are no reports about this...

Andreas