composite and smooth moving (double buffering?)

Anders Storsveen wakko at generation.no
Tue Oct 4 23:44:25 PDT 2005


Thomas Lübking wrote:

>Am Mittwoch, 5. Oktober 2005 03:26 schrieb Anders Storsveen:
>  
>
>>When I enable composite and try to drag the konqueror window around
>>fast, the window will move very smooth, although very slow to, but
>>that's another issue (probably nvidia's rendr acceleration that is slow
>>right?).
>>    
>>
>rather xaa composite implementation (i.e cache limitation?, try to reduce 
>resolution and/or bpp) or because you didn't activate the
>Option     "RenderAccel" "true"
>(btw, randr but rend_e_r)
>also it might be that the "nvidia" driver (nVidias CSS stuff) is faster than 
>the "nv" driver that comes with X
>
>  
>
>>However, this smooth moving, which only happens to qt apps, why is this?
>>    
>>
>hää? toolkit doesn't matter here (i.e. xterm is as smooth as konsole or 
>gnome-terminal) - what exactly do you mean by run "not smooth"?
>however, i guess it's rather a matter of the window size
>also gtk1 apps run ARGB, i.e. they eat more cache space for the alpha channel 
>- try to run it exporting XLIB_SKIP_ARGB_VISUALS="1"
>  
>
by noy smooth I mean, my konqueror window runs with out like any
tearing/misrendering when moving fast, however my eterm window, and
thunderbird window runs much faster, but not as smooth (and
"error"-free, since I see rendering glitches or "tearing". so it seems
that the konqueror window is running just as fast as the compositer can
run it and also render each frame complelty, however eterm and
thunderbird seem to run unhindered, but with tearing, i did mean RENDER
and I have RenderAccel "1".

>  
>
>>Could someone please explain this to me, also how it works :)
>>    
>>
>basically the window content is rendered into an offscreen buffer, redirected 
>into an application (the compmgr, probably kompmgr for kde) and there used to 
>draw a fullsize picture onto the root window.
>the compmgr then can do funny things on this (like adding translucency or 
>shadows etc.)
>
>Thomas
>  
>




More information about the xorg mailing list