Faster window resize in a composite manager

[David Reveman]

On Sun, 2007-11-18 at 04:15 +0100, Dennis Kasprzyk wrote:
> 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.

Sure, I'm all for improving the server if it makes sense. An
window-pixmap changed event might be a good solution. You can't really
add XCompositeSetWindowPixmapSize without such an event as it wouldn't
be possible for other clients than the one who sent the pixmap-size
request to use the window pixmap otherwise...

-David