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 544072 - GTK+ calls XRRGetScreenResources() altogether far too frequently
GTK+ calls XRRGetScreenResources() altogether far too frequently
Status: RESOLVED DUPLICATE of bug 571574
Product: gtk+
Classification: Platform
Component: .General
2.13.x
Other All
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: randr-tracker
 
 
Reported: 2008-07-21 22:52 UTC by Ben Gamari
Modified: 2009-03-06 03:48 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description Ben Gamari 2008-07-21 22:52:52 UTC
Please describe the problem:
GTK+ seems to call XRRGetScreenResources() on startup. This is an expensive call and causes the X server to probe outputs. This means that every time a GTK+ application is started, all outputs lose and must regain sync. This is Very Bad(TM).

Original xserver bug: https://bugs.freedesktop.org/show_bug.cgi?id=16224
Mailing list thread: http://lists.freedesktop.org/archives/xorg/2008-July/037365.html

Steps to reproduce:



Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Matthias Clasen 2008-07-21 22:56:52 UTC
pretty clearly an issue on the X side of the fence...
Comment 2 Ben Gamari 2008-07-22 05:33:49 UTC
If you read the thread and original bug report, you will see that the X people strongly disagree. XRRGetScreenResources() is currently designed to be a very expensive call:

"XRRGetScreenResources is an expensive call.  Always.  If gtk is calling it on every app startup they're absolutely insane." -- David Airlie
Comment 3 Matthias Clasen 2008-07-22 12:32:24 UTC
At least get your quoting right. Ajax said that, not airlied.
Comment 4 Eric Piel 2008-07-22 13:15:26 UTC
I have the same problem here. Concerning the reproduction of the bug, I think it depends on the video driver. It happens only if it re-asks for EDID at each call to XRRGetScreenResources() (which, according to the Xorg maintainers, is the right thing to do). At least, with the intel driver, it happens.

IMHO I feel like asking again for the EDID, even if the screen has not changed is rather useless. It also leads to all the programs using xrandr to cause my screen to flicker. However, I would like to suggest disabling the call in gtk until this is resolved. Having the screen flickering each time an application starts is just purely unacceptable from the point of view of the user :-(
Comment 5 Loïc Minier 2008-08-26 11:06:11 UTC
So solutions I can think of here:
a) request new API at xorg: anyone opened a bug for this?
b) stop using the API altogether: what's the impact on gtk?
c) use the API as little as possible, perhaps moving the information to a per-session location (e.g. xsettings); we could either move updating of this information to some other layer, or update it from whatever gtk app starts first, or periodically

Is there any mailing-list thread discussing the issue with the API or lack of API for the information gtk is interested in, without reprobing outputs?

Thanks,
Comment 6 Matthias Clasen 2008-08-26 13:38:58 UTC
You can find ajax' patch for a more suitable xrandr api on xorg-list
Comment 7 Loïc Minier 2008-08-26 15:27:39 UTC
Thread: http://lists.freedesktop.org/archives/xorg/2008-July/thread.html#37365
Patch in msg: http://lists.freedesktop.org/archives/xorg/2008-July/037459.html
Patch to the spec/headers: http://people.freedesktop.org/~ajax/patches/randrproto-1.3.patch

AIUI, this still needs:
 * implementation in xrandr drivers and server
 * new xrandr, server and driver releases

doesn't look like we'll get that anytime soon, so should usage of this API be reverted in Gtk+ until this is available?
Comment 8 Federico Mena Quintero 2009-03-05 19:01:14 UTC
Isn't this a duplicate of bug #571574?
Comment 9 Matthias Clasen 2009-03-06 03:48:41 UTC
Kinda

*** This bug has been marked as a duplicate of 571574 ***