Bug 23412

Summary: slow resizing and "moving-over" certain windows, heavy CPU load while resizing
Product: xorg Reporter: flo <florian.a.jung>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: medium CC: hramrach, pmb
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
my xorg.conf
none
my xorg.0.log none

Description flo 2009-08-19 10:05:58 UTC
Created attachment 28783 [details]
my xorg.conf

when i try to resize certain windows, like "firefox", "compiz settings manager" or "audacity", my mouse moves, but not the window-corner i clicked at. some seconds later, the window corner "jumps" to my mouse pointer and then it rests there again. some other seconds later it jumps again, and so on...

while this action, top tells me that i have 100 percent CPU load, the major part for X and the minor part (between 10 and 40%, varies from program to program) for the resized window.

another thing i noticed is, when i move a "normal" window (one that doesn't resize so slow) over such a "slow-resizing" window, the "slow-resizing" window is only repainted in some seconds. while that, my CPU load is also higher than usual (but not 100%).

i _assume_ that the problem lies in the repainting of the windows in general, but i dunno.

the problem occurs with openbox, xfwm4 and compiz with and without effects as windowmanager. (all of them are repainting the content of the window while moving/resizing.)

i've got an ATI radeon mobility 9800 and i'm using the radeon driver V6.12.2 and Xorg Version 1.6.3

steps to reproduce:

open the compiz settings manager (ccsm)
resize it

OR:

open the ccsm and maximize it
open another window, for example a terminal
have the ccsm-window behind the terminal-window and move the terminal window around.

actual results: slow and CPU-intensive repainting of the windows (1-2 FPS)
expected results: smooth and fast repainting of the windows (>10FPS. at least!)

Xorg -version says the following:
X.Org X Server 1.6.3
Release Date: 2009-7-31
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.30-ARCH i686 
Current Operating System: Linux arch 2.6.30-ARCH #1 SMP PREEMPT Fri Jul 31 18:10:38 UTC 2009 i686
Build Date: 14 August 2009  11:31:10AM


it's really annoying, because it renders my system almost unusable (i don't like waiting 10 seconds for resizing a window ._.)
Comment 1 Alex Deucher 2009-08-21 08:25:36 UTC
Please attach you xorg log as well.
Comment 2 flo 2009-08-21 08:27:46 UTC
Created attachment 28837 [details]
my xorg.0.log
Comment 3 Michel Dänzer 2009-08-21 09:26:50 UTC
IME this can be due to the apps / toolkit at least as much as it is due to the X server / driver.

As a workaround, most window managers allow you to configure different methods of window resizing which don't require constant redraws by the apps.
Comment 4 Pauli 2009-08-21 10:03:05 UTC
updates from irc:

with compiz sysprofile shows that problem is pixmapBltsse2.
(07:14:30 PM) flo|linux: pixmapBltsse2 has 82.18
(07:14:41 PM) flo|linux: the next smaller value is 4
(07:19:03 PM) flo|linux: without compiz it's much faster after tweaking the xorg.conf
(07:19:14 PM) flo|linux: and pixmanBltsse2 only has 12.88%
(07:19:20 PM) flo|linux: in kernel is 14.04%

So for compiz case it should be found out what is calling pixmapBltsse2 and then either looking for way to reduce the number of calls or optimise that function.

PS. Sorry for going afk.
Comment 5 Michal Suchanek 2012-04-25 03:27:07 UTC
It's probably because the application is doing lots of work while resizing the window. It's not unusual for Firefox to take ages to repaint, especially when resized.

To support applications like Firefox the WM should display the new window size using 'rubberband' or similar graphics until the application manages to repaint.
Comment 6 Alex Deucher 2012-04-25 05:56:46 UTC
Is this still an issue?
Comment 7 Michal Suchanek 2012-04-25 09:35:55 UTC
Yes, Firefox is still slow to redraw and takes lots of CPU time to do so.

My windowmanager paints the window frame just fine even when firefox window content is not redrawn, however.
Comment 8 Marius Bjørnstad 2013-01-17 00:11:44 UTC
I am seeing this issue as well, especially with graphics-heavy pages in Firefox. It happens with all applications, but less frequently. It started happening for me after I upgraded the memory and CPU. I made a video of me trying to resize Firefox, but it may not be of much use http://www.fa2k.net/misc/firefox-resize.mp4 

My graphics card is a Radeon 6700.
Comment 9 Marius Bjørnstad 2013-01-17 00:17:04 UTC
6770* (sorry for the spam, I couldn't edit)
Comment 10 Marius Bjørnstad 2013-01-17 00:21:12 UTC
Sorry, not the same problem after all. Audacity does not freeze, it's just somewhat slow, so the freezing firefox problem I had is different. I'll submit a bug for that later when I have time. Sorry for writing three messages.
Comment 11 Martin Peres 2019-11-19 07:29:19 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/6.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.