Version:           4.1.2 + panel autohide from trunk (using KDE 4.1.2)
Compiler:          g++ 4.3 
OS:                Linux
Installed from:    Fedora RPMs

This is a bug we noticed while testing a backport of panel auto-hiding to KDE 4.1.2, but I believe it also affects the trunk: after applying:
1. this backport from trunk:
http://cvs.fedoraproject.org/viewvc/rpms/kdebase-workspace/devel/kdebase-workspace-4.1.2-panel-autohide.patch?revision=1.2&view=markup
and
2. http://websvn.kde.org/?view=rev&revision=866710
Plasma's CPU consumption when idle with the panel shown raises to insane levels (on several different machines): with compositing enabled, it's around 20-50%, with compositing disabled, around 99-100% (!). If I disable revision 866710 (and revision 866715 which I had included in the same backport: http://cvs.fedoraproject.org/viewvc/rpms/kdebase-workspace/devel/kdebase-workspace-4.1.2-panel-autohide-fix-flicker.patch?revision=1.2&view=markup , but I doubt it's that one as it only touches the panel controller which isn't being shown at all when this happens), the CPU consumption is back down to reasonable levels.

I believe the offending change to be the one to the event handler:
+bool PanelView::event(QEvent *event)
+{
+    if (event->type() == QEvent::Paint) {
+        QPainter p(this);
+        p.setCompositionMode(QPainter::CompositionMode_Source);
+        p.fillRect(rect(), Qt::transparent);
+    }
+    return Plasma::View::event(event);
+}
This resets the background to transparent at *every single* paint event! And it does this even if the panel is being permanently shown (even with autohide disabled), which is way overkill for a patch which fixes flicker while the autohiding animation is being shown. I guess there's a missing conditional there to check for whether we're actually running the animation at this point before resetting the background to transparent.