--===============0124214754719459104== Content-Type: multipart/alternative; boundary="===============1539927712711356692==" --===============1539927712711356692== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > On Aug. 27, 2011, 4:45 p.m., Philipp Knechtges wrote: > > kwin/composite.cpp, lines 714-715 > > > > > > Sry for the late comment, but shouldnt we at least drop the damage = events from the event queue. > = > Thomas L=C3=BCbking wrote: > "Why"? afaik the queue is wiped with the next cycle anyway and testin= g didn't show any difference in the XPending() count whether i remove the d= amage events or not > (Surprisingly the performance doesn't improve either - at least not s= ignificantly) > = > Do you spot any leaks or other issues? > = > Philipp Knechtges wrote: > My concern was just of theoretical interest. I just wasn't aware that= these events are wiped out at the end of the cycle and believed therefore = that the damage events would be scheduled as unnecessary repaints in the ne= xt frame. But I'm still curious where exactly kwin tells the X Server to cl= ean the event queue because we never call XSync(display(), true) directly? Nowhere. I frankly thought Q/KApplication would. However *another* test (di= fferent debug code) simply blocked compositing completely w/o dropping the = events, so a) good catch - thanks alot b) check http://commits.kde.org/kde-workspace/562cabc9e76c8af356a68e9114793= 4e80ae4e78b c) I'm gonna inspect the Qt event management to know for sure ;-) - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101861/#review6068 ----------------------------------------------------------- On July 5, 2011, 10:32 p.m., Thomas L=C3=BCbking wrote: > = > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101861/ > ----------------------------------------------------------- > = > (Updated July 5, 2011, 10:32 p.m.) > = > = > Review request for kwin. > = > = > Summary > ------- > = > Client updates are expensiv to the compositor. > While KWin limits the framerate (vsync or not) the client still can send = a bazillion damage notifications between two frames w/o any gain on screen. > = > So far the handling is pretty expensive. > a) KWin would handle the damage notification even though the window is st= ill tagged completely damaged. > b) It uses QRegion operations, though we know that the rects in the damag= e notification won't overlap (and the region is added rectwise, causing mor= e QRegion ops anyway) > c) it allows up to 200 rects but doesn't care about the damage ratio befo= re the window is "just completely damaged" > = > The patch changes this. > = > Target are high frequently updating clients, possibly using XShape. > @Martin: do you recall that Java IDE you confirmed to perform horribly un= der composition? Can you test it against this patch? > Are there still known clients using XShape for text DnD? > = > I tried (and actually figured the problem) phoronixing KWin against Mutte= r (wanted to know about all that FUD) and figured that Mutter did actually = "better" until i turned off the resize handle (Bespin, but Oxygen has a com= parable thing) which causes glxgears to damage in 12 rects. ("only") > = > In consequence of the patch the kwin CPU usage dropped from constant over= all 25% to constant 15% (and the 10% being distributed to glxgears and X11)= - ie. a 40% improvement (and higher framerates!!) > = > Yes, i know that glxgears is special, no i'm not optimizing towards phoro= nix results, yes Martin, i've read the article - not that it was new to me = ;-) > = > = > Diffs > ----- > = > kwin/composite.cpp 8c87984 = > kwin/toplevel.h 35f1bb5 = > = > Diff: http://git.reviewboard.kde.org/r/101861/diff > = > = > Testing > ------- > = > Yes, phoronixing. > = > = > Thanks, > = > Thomas > = > --===============1539927712711356692== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
This is an automatically generated e-mail. To reply, visit: http://git.revie= wboard.kde.org/r/101861/

On August 27th, 2011, 4:45 p.m., Philipp Kn= echtges wrote:

= = = = =
kwin/composite.cpp (Diff revision 1) 
Pixmap Toplevel::createWindowPixmap()
712 
    QRegion damage(e<=
span class=3D"o">->area.x, e->area<=
span class=3D"p">.y, e->area.width, e->area.=
height);
 714 
    if (damageRatio =3D=3D 1.0) // we know that we're completely damaged, no need to tell us ag=
ain
 

    715
    
        return;

  


 




  
Sry for t=
he late comment, but shouldnt we at least drop the damage events from the e=
vent queue.

 




 
On August 27th, 2011, 9:34 p.m., Thomas L=C3=BCbking wrote:

 

  
"Why=
"? afaik the queue is wiped with the next cycle anyway and testing did=
n't show any difference in the XPending() count whether i remove the da=
mage events or not
(Surprisingly the performance doesn't improve either - at least not sig=
nificantly)

Do you spot any leaks or other issues?

 






 
On August 27th, 2011, 11:37 p.m., Philipp Knechtges wrote:

 

  
My concer=
n was just of theoretical interest. I just wasn't aware that these even=
ts are wiped out at the end of the cycle and believed therefore that the da=
mage events would be scheduled as unnecessary repaints in the next frame. B=
ut I'm still curious where exactly kwin tells the X Server to clean the=
 event queue because we never call XSync(display(), true) directly?

 











Nowhere. I frankly thought Q/KApplication would. However *another* t=
est (different debug code) simply blocked compositing completely w/o droppi=
ng the events, so
a) good catch - thanks alot
b) check http://commits.kde.org/kde-workspace/562cabc9e76c8af356a68e9114793=
4e80ae4e78b
c) I'm gonna inspect the Qt event management to know for sure ;-)








- Thomas






On July 5th, 2011, 10:32 p.m., Thomas L=C3=BCbking wrote:









 

  


Review request for kwin.


By Thomas L=C3=BCbking.




Updated July 5, 2011, 10:32 p.m.






Descripti=
on 



 

  
   
Client updates are expensiv to the compositor.
While KWin limits the framerate (vsync or not) the client still can send a =
bazillion damage notifications between two frames w/o any gain on screen.

So far the handling is pretty expensive.
a) KWin would handle the damage notification even though the window is stil=
l tagged completely damaged.
b) It uses QRegion operations, though we know that the rects in the damage =
notification won't overlap (and the region is added rectwise, causing m=
ore QRegion ops anyway)
c) it allows up to 200 rects but doesn't care about the damage ratio be=
fore the window is "just completely damaged"

The patch changes this.

Target are high frequently updating clients, possibly using XShape.
@Martin: do you recall that Java IDE you confirmed to perform horribly unde=
r composition? Can you test it against this patch?
Are there still known clients using XShape for text DnD?

I tried (and actually figured the problem) phoronixing KWin against Mutter =
(wanted to know about all that FUD) and figured that Mutter did actually &q=
uot;better" until i turned off the resize handle (Bespin, but Oxygen h=
as a comparable thing) which causes glxgears to damage in 12 rects. ("=
only")

In consequence of the patch the kwin CPU usage dropped from constant overal=
l 25% to constant 15% (and the 10% being distributed to glxgears and X11) -=
 ie. a 40% improvement (and higher framerates!!)

Yes, i know that glxgears is special, no i'm not optimizing towards pho=
ronix results, yes Martin, i've read the article - not that it was new =
to me ;-)

  		
 






Testing <=
/h1>


 

  
   
Yes, phoronixing.

  		
 








Diffs=
 


    

 
  • kwin/composite.cpp (8c87984)
    • 

 
  • kwin/toplevel.h (35f1bb5)
    • 





View Diff





  		
 











  

 



--===============1539927712711356692==--

--===============0124214754719459104==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin

--===============0124214754719459104==--