New window pixmap initialization

New window pixmap initialization

[Jacopo De Simoi]

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

Re: New window pixmap initialization

[Jacopo De Simoi]

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-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>