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 ._.)
Please attach you xorg log as well.
Created attachment 28837 [details] my xorg.0.log
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.
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.
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.
Is this still an issue?
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.
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.
6770* (sorry for the spam, I couldn't edit)
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.
-- 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.