After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 568874 - moving glxgears- and movie windows is very sluggish
moving glxgears- and movie windows is very sluggish
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks: 585500
 
 
Reported: 2009-01-23 17:08 UTC by Achim Frase
Modified: 2009-06-30 13:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Regularize main loop priorities (6.50 KB, patch)
2009-06-11 21:29 UTC, Owen Taylor
none Details | Review

Description Achim Frase 2009-01-23 17:08:38 UTC
Please describe the problem:
If you run glxgears or a movie with totem the window movement gets really sluggish.

My System:
Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz
GeForce 8600 GT driver version is 180.22
X.Org X Server 1.5.2
Current Operating System: Linux 2.6.27-9-generic #1 SMP x86_64

Steps to reproduce:
1. simply start a movie or glxgears and try to move the window around.


Actual results:
The CPU usage gets very high, sometimes up to 100%.

Expected results:
The window should move very smooth like with compiz.

Does this happen every time?
This happens to 98% of the time.

Other information:
Maybe it is a nvidia driver bug, but I don't know at the moment.
I will do some further testing on my GMA945 when DRI2 hits the streets.
Comment 1 Achim Frase 2009-02-11 14:49:26 UTC
I have noticed that the window movement gets sluggish especially with HD-Content.

If I run for example 'Crack Attack' (little OpenGL game http://aluminumangel.org/attack/ ) I am almost not able to activate the overly mode with the mouse by clicking on the activities button on the panel.
Comment 2 drago01 2009-05-25 17:57:20 UTC
I can confirm this ... when glxgears is running moving windows is a lot slower (not only the glxgears window but every window). While with compiz running glxgears does not cause any (noticeable) performance degradation.
Comment 3 Owen Taylor 2009-06-11 21:28:25 UTC
This largely was fixed by the Clutter change from today to change the redraw priority to be lower than the GTK+ redraw priority (and thus lower than META_PRIORITY_RESIZE), but there are still remaining issues because some of the other Mutter priorities are lower than CLUTTER_PRIORITY_REDRAW

(for example, minimizing windows never takes effect when a constantly-drawing client like glxgears is running)

I'll attach a patch that tries to sort everything out.
Comment 4 Owen Taylor 2009-06-11 21:29:04 UTC
Created attachment 136368 [details] [review]
Regularize main loop priorities

If there is a client that is continually redrawing, then
sources that are less-prioritized than CLUTTER_PRIORITY_REDRAW
will never get run. This patch sorts out how all the different
main loop sources fit in CLUTTER_PRIORITY_REDRAW.

common.h: Document all the relevant priorities and how they
  fit in with each other.
ui.h common.h: Move META_PRIORITY_RESIZE to to common.h with
  other priorities.
src/core/window.c src/core/screen.c: Change calc-showing,
  update-icon, and update-work-area idles to be prioritized above
  redraws so they don't get starved.
bell.c: Make the visual bell priority the same as the clutter
  redraw priority.
delete.c: Use a G_PRIORITY_DEFAULT idle when responding to the
  dialog response; we want to handle it as soon as practical.
Comment 5 Owen Taylor 2009-06-30 13:46:45 UTC
Due to git misadventure, this somehow got merged into:

commit 51a646796896312b1bdfdb2ddf46379e3fccced7
Author: Jon Nettleton <jon.nettleton@gmail.com>
Date:   Wed Jun 10 12:29:20 2009 +0200

    Comprehensively rename to Mutter

When I was applying that patch, so it's been in the source tree for a few weeks.