Version: (using KDE 4.4.2) Installed from: Ubuntu Packages When I hit f12 i very often have to wait about 2 sec. until yakuake window appears. The animation is also not fluent. The same is true for hiding.
That's usually a graphics driver problem, please look into updating those or whether there is a decent driver for your card at all. nVidia's drivers have serious performance issues with bitmap fonts, for example.
STOP blaming this recurring, crippling problem on other people's code like nVidia drivers or Konsole. On the same machine, with the same graphics card, with the same drivers, the Konsole program is PERFECTLY CAPABLE of restoring its window from minimized state IN A BLINK, while Yakuake takes UNBELIEVABLE 6 SECONDS.
You're reacting to something written *five years ago*.
No, I'm reacting to *a bug that hasn't been fixed for five years, and keeps being repeatedly re-blamed on whatever software artifact happens to be the fashionable blame target of the month*.
Except the Yakuake animation system has actually changed quite drastically within those five years. See the "Ask the window manager to perform the animation" option in the config dialog, enabled by default. The animation is farmed out to the compositor (kwin) today, and performed with OpenGL acceleration where available. It's the same code doing all animated window slides in Plasma, including e.g. various panel popup reveals. The animation strategy used at the time this ticket was opened remains as a fallback solution (not running inside Plasma, or not having compositing available) and is about as fast as it will ever be, since its performance is subject to external factors. The comparison to Konsole is invalid, since you're either talking about an animation performed by the window manager (and we've long since taught Yakuake the same trick, see above) or no animation (which you can achieve by setting the animation duration to 0 in the Yakuake config dialog). Listen though, let's be very, very clear: I'm writing this for the benefit of others. The behavior you put on display is entitled, dick-ish and unacceptable, and I'm not interested in you using my software.
> See the "Ask the window manager to perform the animation" option > in the config dialog, enabled by default. I remember when it was introduced. I tried it back then, and it had no effect on this particular problem (it did have an effect on the smoothness of the closing animation though). It has no effect on this problem today either. > or no animation (which you can achieve by setting the animation duration > to 0 in the Yakuake config dialog) First thing done. It has no effect though: I can set the duration to 0ms and there's still the 6s delay, or I can set it to 500ms and the 6s pause transpires in its entirety before the animation starts. This is also independent of the "Ask WM to perform animation" option.
With the animation taken out, the window show is basically just a straight call to QWidget::show(), so there's not a whole lot going on in the Yakuake code. Six seconds is far above any sort of realistic performance variance, so there has to be something seriously broken, and the focus should be on diagnosing where that delay happens. If you're opening Yakuake by re-running the executable, which ends up looking for an existing instance on D-Bus and contacting it via D-Bus to open itself, the delay might be in the D-Bus communication. If you're opening Yakuake by keyboard shortcut, the delay might be in handling the shortcut event. I recommend experimenting with the different ways and/or using profiling tools to figure out where the time is eaten up, and then one can look at the why, and what might be done about it. That's what I'd do if I saw Yakuake opening take six seconds somewhere, which hasn't been the case, however.
Also, if you're using a Qt 4-based Yakuake, try running it with either QT_GRAPHICSSYSTEM=render or QT_GRAPHICSSYSTEM=native and see whether the situations changes.
> Also, if you're using a Qt 4-based Yakuake Yakuake Wersja 2.9.9 Platforma KDE 4.14.8 That would be Qt4, right? What I neglected to mention is that I usually run without compositing, so this is the context of the problem. I just turned compositing on and yakuake works smoothly so far, but that's probably a false trail since X crashed on me when I enabled compositing so this is probably what cleared the congestion. Will try various settings now (including QT_GRAPHICSSYSTEM).
^ Aye, that's Qt 4.