Am Dienstag, 13. November 2007 22:36:13 schrieb David Reveman:
> On Tue, 2007-10-16 at 14:54 +0200, Dennis Kasprzyk wrote:
> > Hi,
> >
> > I've implemented my idea from my "Idea how to fix slow window resize in a
> > composited desktop" post. My patches add a new function
> > XCompositeSetWindowPixmapSize to Xcomposite. The compositing manager can
> > use this function to set the window pixmap to the desired size, and the
> > xserver will not change the pixmap and it's size during a resize. If
> > XCompositeSetWindowPixmapSize is called with 0/0 as size, the xserver
> > switches back to it's current pixmap handling and resizes the current
> > pixmap back to the window size.
>
> I fail to see how this would improve performance while my suggestion of
> reparenting the window we're resizing to a larger temporary top level
> window doesn't. It should end up the same thing as far as the DDX care,
> or am I missing something?
>
> -David

I've tried to implement your idea and I haven't seen any performance 
improvement, but maybe this was caused by a mistake that I've made during the 
implementation of your idea. After getting some responses for my idea on the  
mailinglist/irc, I think that it would make more sense to improve the 
composite extension and not to try to workaround our problems directly in the 
composite manager.

Currently we assume that the window pixmap matches also the window size and we 
also assume that the window pixmap changes (and call 
XCompositeNameWindowPixmap) with each window resize. Due to some hardware 
limitations it could make sense to to keep the redirected window (and pixmap) 
size, in limits that could be fully/better hardware accelerated. For example 
it could make sense for some hardware platforms to make the window pixmap 
dimensions always be an even number or divisible by 8, to achieve better 
performance. The best solution to achieve this, would be a new event, that 
informs the composite manager that the window pixmap has been changed. This 
event could also contain all information's about the window pixmap, to avoid 
the need to call XGetGeometry. An XCompositeSetWindowPixmapSize could then 
inform the xserver/ddx that the window will be resized and that it would make 
sense to resize the pixmap to the given dimensions, and the xserver/ddx could 
decide what should be done. Looking at the current resize performance in Xgl 
for example there should be no need to resize the window pixmap because 
resizing in Xgl seams to be fast enough (on my hardware). For the current 
AIGLX/Nvidia texture-from-pixmap implementations (tested with nvidia & fglrx 
aiglx) it would make more sense to resize the window pixmap to big dimesions 
if the composite manager thinks that the window size will changed multiple 
times.

Even if we could workaround the current bad resize performance directly in 
compiz, I still think that it would make more sense to provide flexible 
window pixmap system directly in the xserver.
I know that my patches may be not fully correct, but maybe someone with enough 
knowledge about the xserver will find the time to do it right.

Dennis

_______________________________________________
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg