Nouveau - Mar 2011 - New window pixmap initialization

Hello nouveau devs

I'd like some informations on the pixmap initialization for a new window in
a (xrender) composited setting; I'm currently trying to improve the xrender
backend of
kwin (i.e. kde composited window manager) and I'm facing some issues which
might
or might not be driver related.

From what it seems, when a new window is created with geometry (x y w h)
the pixmap is first initialized with the content of the screen in the rect (x y
w h),
is this correct?

This actually is causing glitches with effects that animate the appearance of
the given window
by some kind of motion, since one can see for a split second a portion of screen
moving for no reason
and afterwards the new window appearing (as soon as it has been first painted).

Imvho, if an argb window is created, it would  be much much cleaner to init its
pixmap with a fully
transparent color; trying to implement this in the wm is kind of weird; on the
other hand
I got pretty quickly lost examining ddx code, so I have a few questions:

1? Is first pixmap creation in a composited setting driver dependent?
2? I assume that upon creation the contents of the pixmap should actually be
undefined
    and are init'd like I said for purely convenience reasons; is this
correct? is there anything in the specs about that
    which I did not see?
3? Would it be possible for the nouveau driver to implement the alternate
initialization strategy for argb windows?
    Does the new strategy make sense to you?
4? I'd be happy to provide a patch for point 3, provided that somebody helps
me out with finding the right place
    for it; 

Thanks a lot;
__J

P.S. I'm always on IRC, nick wilder

Nevermind, I found out that it was a bizarre strategy of Qt for some specific
window types
apologies for the noise

 _J
> Hello nouveau devs
> 
> I'd like some informations on the pixmap initialization for a new
window in
> a (xrender) composited setting; I'm currently trying to improve the
xrender backend of
> kwin (i.e. kde composited window manager) and I'm facing some issues
which might
> or might not be driver related.
> 
> From what it seems, when a new window is created with geometry (x y w h)
> the pixmap is first initialized with the content of the screen in the rect
(x y w h),
> is this correct?
> 
> This actually is causing glitches with effects that animate the appearance
of the given window
> by some kind of motion, since one can see for a split second a portion of
screen moving for no reason
> and afterwards the new window appearing (as soon as it has been first
painted).
> 
> Imvho, if an argb window is created, it would  be much much cleaner to init
its pixmap with a fully
> transparent color; trying to implement this in the wm is kind of weird; on
the other hand
> I got pretty quickly lost examining ddx code, so I have a few questions:
> 
> 1? Is first pixmap creation in a composited setting driver dependent?
> 2? I assume that upon creation the contents of the pixmap should actually
be undefined
>     and are init'd like I said for purely convenience reasons; is this
correct? is there anything in the specs about that
>     which I did not see?
> 3? Would it be possible for the nouveau driver to implement the alternate
initialization strategy for argb windows?
>     Does the new strategy make sense to you?
> 4? I'd be happy to provide a patch for point 3, provided that somebody
helps me out with finding the right place
>     for it; 
> 
> Thanks a lot;
> __J
> 
> P.S. I'm always on IRC, nick wilder
> _______________________________________________
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>