... i came across a somewhat common problem in the taskbar: a rather expensive function was called from a number of different code paths which sometimes would be executed in quick succession one after the other.
in this particular case, it was the method that sets the geometry for all the buttons in the taskbar, both resizing and positioning them, which in turn triggers repaints. ai!
it was being called repeatedly whenever there were several "this window has changed in some way" type events created, such as when switching desktops, opening several windows or closing a set of windows. none of these calls could be removed, though, since sometimes only one of the code paths gets executed, depending on what is happening, and the layout still needs to get updated in that case. worse yet, sometimes the layout method would be called while it was still in the layout method due to hitting the event loop while doing lay outs and new events being processed which caused calls to the layout method. ug.
so i employed a dirty little trick that i've used elsewhere in similar situations:
void TaskBar::TaskBar()
{
...
connect(&m_relayoutTimer, SIGNAL(timeout()),
this, SLOT(reLayout()));
...
}
void TaskBar::reLayoutEventually()
{
m_relayoutTimer.stop();
if (!blocklayout)
{
m_relayoutTimer.start(200, true);
}
}
all calls directly to reLayout() were then replaced with reLayoutEventually(). the expensive reLayout() method is now called at most five times a second and in practice is only called one per set of events, which keeps the taskbar feeling more responsive.
it's a cheap and even common trick, but it works.
p.s. kdBacktrace(int) rocks
1 comment:
This is a nice way to optimize stuff, and I somehow have the feeling that other parts of KDE could benefit from the same kind of optimizations, my thoughts are
pointing me to the tabbar of konqueror which still performs too many repaints, it feels even life it repaints while the a new tab is created
Post a Comment