Bug 8499 - slow resizing of windows
Summary: slow resizing of windows
Status: RESOLVED WORKSFORME
Alias: None
Product: xorg
Classification: Unclassified
Component: App/compiz (show other bugs)
Version: 7.1 (2006.05)
Hardware: x86 (IA32) Linux (All)
: high enhancement
Assignee: David Reveman
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-03 15:29 UTC by Hannes Janetzek
Modified: 2008-07-12 15:27 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Hannes Janetzek 2006-10-03 15:29:16 UTC
i wanted to ask what is the reason for the slow updates when resizing windows.
the slowness is one of the main points that keeps me from using compiz as my
regular window manager.

thanks in advance
Comment 1 Daniel Stone 2007-02-27 01:33:50 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 2 kronheim 2007-03-11 06:09:31 UTC
There's something strange about resizing with the mouse that goes beyond slowness. I experience the following with Acrobat Reader, Firefox and Thunderbird:

(1) Open a window, filling less than full screen.
(2) Left-click the right-hand border to begin a drag.
(3) Drag the right-hand border to the right; do not release the mouse.
(4) Wait, while still holding the left mouse button down, but not moving it.

Expected result: The window is eventually redrawn with its right-hand border at the position of the mouse.

Actual result: The mousse cursor may be three inches past the edge of the window, but the window never resizes. The window will not resize until the mouse twitches again (i.e. move the mouse a little more).

It seems that a redraw is triggered only by a mouse movement: as long as the mouse is stationary during the drag, the window will not be redrawn, even if the mouse position is well outside the window.
Comment 3 David Reveman 2007-03-11 12:17:11 UTC
Resizing a redirected window on composited desktop is much more expensive than resizing a window on a regular desktop. Mainly because you have to allocate a new buffer for the window, copy the old contents to this new buffer and wait for the application to redraw missing parts. On a regular desktop you just change the clipping region for the window and have the application redraw missing parts.

The strange resizing issue you noticed should now be fixed. Thanks for reporting that one.
Comment 4 Martin Ejdestig 2007-11-14 10:07:47 UTC
Anyone working on this?
Comment 5 Hannes Janetzek 2007-11-14 10:17:14 UTC
big thanks to everyone working on compiz and the free ati drivers. the problem is solved for me now with a regular ubuntu gutsy install. 
Comment 6 Martin Ejdestig 2007-11-14 10:40:22 UTC
It is? I figured Gutsy was using the resize mode it does just because this preformance problem was still around.


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.