[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Review Request: Analog clock painting performance
From:       "Aaron Seigo" <aseigo () kde ! org>
Date:       2008-11-30 17:01:15
Message-ID: 20081130170115.3932.82071 () vidsolbach ! de
[Download RAW message or body]


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.vidsolbach.de/r/290/#review275
-----------------------------------------------------------


hm. that seems a little suspect to me, but if grabbing the cached rects is really \
that slow, then Theme::findInRectsCache is probably what needs to be optimized.

can you post the cachegrind output somewhere, along with the clock configuration you \
used?




/trunk/KDE/kdebase/workspace/plasma/applets/analog-clock/clock.cpp
<http://reviewboard.vidsolbach.de/r/290/#comment227>

    upon changing the theme, these will now be incorrect until a resize is made.



/trunk/KDE/kdebase/workspace/plasma/applets/analog-clock/clock.cpp
<http://reviewboard.vidsolbach.de/r/290/#comment226>

    two lines back you translate QSize(center, center) and now translate back \
-QSize(center, center)? the reason why the previous translation had all that crazy \
"translate based on the element size" is to make sure the elements always line up.  
    now the assumption is that the element is == boundingRect/2
    
    i also wonder if this should be using boundingRect as opposed to contentsRect, \
but that's another topic =)



/trunk/KDE/kdebase/workspace/plasma/applets/analog-clock/clock.cpp
<http://reviewboard.vidsolbach.de/r/290/#comment224>

    are you sure about that?



/trunk/KDE/kdebase/workspace/plasma/applets/analog-clock/clock.cpp
<http://reviewboard.vidsolbach.de/r/290/#comment225>

    this paints the center screw in a completely different way, now doesn't it? that \
it still works the same is probably a fluke of the oxygen clock svg.


- Aaron


On 2008-11-30 07:32:56, Alain Boyer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.vidsolbach.de/r/290/
> -----------------------------------------------------------
> 
> (Updated 2008-11-30 07:32:56)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> -------
> 
> This patch attempts to speed up the analog clock painting performance. Essentially, \
> it caches the QRects of the theme elements and streamlines some of the painting \
> code. 
> The speedup is explained below, however I think we can do even better. For example, \
> we could draw the hour and minute hands and shadows to a pixmap and then use that \
> when only the second hand needs an update. I'm not sure if this is the way to go? \
> Comments or suggestions? 
> 
> Diffs
> -----
> 
> /trunk/KDE/kdebase/workspace/plasma/applets/analog-clock/clock.h
> /trunk/KDE/kdebase/workspace/plasma/applets/analog-clock/clock.cpp
> 
> Diff: http://reviewboard.vidsolbach.de/r/290/diff
> 
> 
> Testing
> -------
> 
> Valgrind tells me that this patch introduces a 1.46 speedup to the drawHand() \
> method. This contributes to a 1.40 speedup of paintInterface(). Not bad. 
> Another way of looking at it, paintInterface() used to spend 63% of its time \
> actually painting (m_theme->paint()). Now, paintInterface() spends 98% of its time \
> painting. Hence, painting is now the bottleneck. 
> 
> Thanks,
> 
> Alain
> 
> 

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic