Yakuake KDE 4 FAQ (Last update: April 20th, 2009)
  ===================================================

Q: The open/retract animation is very jerky. It was a lot smoother in the
   KDE 3 version on the same system. Why is that?

A: While the specific reasons have yet to be uncovered, this appears to be
   caused by a combination of the Qt 4 toolkit with the proprietary nVidia
   graphics drivers' XRender acceleration framework, especially when using
   a non-scalable bitmap font in the terminal profile. The animation is as
   smooth as it was in KDE 3 with other implementations of XRencer accele-
   ration, e.g. the EXA-based one found in the Intel drivers or even the
   software implementation found in the Xephyr nesting X server. Try using
   a scalable fixed-width font like DejaVu Sans Mono.

   Update March 18th, 2008: Experimental new options added to the nVidia
   drivers in the beta version 171.06 suggest that nVidia may be aware of
   and working to resolve this issue. See:
   http://www.nvnews.net/vbulletin/showthread.php?t=109422

   Update August 19th, 2008: A new beta nVidia driver v177.67 features new
   experimental options that appear to greatly improve KDE 4 and Yakuake
   performance: http://www.nvnews.net/vbulletin/showthread.php?t=118088
   While rendering bitmap fonts still appears to be slower than rendering
   scalable fonts on my own 8800GTX, the difference is significantly redu-
   ced to the point of being usable again. The window animation has gene-
   rally become considerably faster as well, matching or exceeding what is
   found in the KDE 3 version when using a scalable font.

   Update April 20th, 2009: It appears that the performance problem with
   bitmap fonts on nVidia disappears when enabling font anti-aliasing,
   despite anti-aliasing not being applied to bitmap fonts. Presumably
   the codepath used for text display with anti-aliasing enabled is better
   optimized. I observed this behavior with both v180.44 and v180.51 dri-
   vers, i.e. the two latest driver versions, but I don't know if it's
   actually a recent development or not, as I didn't use anti-aliasing
   until now.

   In the future, the Yakuake animation will be done via an effect plugin
   for KDE's window manager, KWin. Performance is expected to greatly im-
   prove then. The old animation code will be kept as a fallback for older
   KDE versions, other desktop environments or for when compositing is not
   enabled/available, however.

  ------------------------------------------------------------------------

Q: There's a flicker in the animation when closing the window. What about
   that?

A: This is caused by a bug in the Fade Out window effect in the KDE window
   manager, kwin, related to how it handles window masks. A fix will be in-
   cluded in KDE 4.0.3 and higher. Alternatively, the effect can be dis-
   abled in System Settings.

  ------------------------------------------------------------------------

Q: I am using KWin Desktop Effects and have the "Shadows" option enabled,
   but the Yakuake window does not have a shadow. How come?

A: Support for shadows for shaped windows (aka windows with a "mask") is
   presently disabled in KWin due to bugs in the relevant code. It is ex-
   pected to be reintroduced in a later KDE release.

  ------------------------------------------------------------------------

Q: I have translucency enabled in my terminal profile, but the terminal
   does not appear translucent in practice. It works in Konsole with the
   "--enable-translucency" command line argument, but not in Yakuake.

A: The Konsole KPart component that Yakuake embeds does not have support
   for XComposite translucency in the KDE 4.0 release. I have contributed
   the required changes to Konsole, and they will be released with KDE
   4.0.1 and later versions. When using a sufficiently new version of the
   kdebase module the "--enable-translucency" command line is not required
   in Yakuake, and in fact not supported.

  ------------------------------------------------------------------------

Q: Translucent areas of my skin look rather different from how they used
   to look in the KDE 3 version. Why is that?

A: While the KDE 4 incarnation of Yakuake tries hard to preserve compati-
   bility with existing skins, the replacement of pseudo-translucency with
   XComposite translucency results in different blending behavior between
   skin elements and their background. Unfortunately this is outside the
   area of influence of the Yakuake code at this time. Translucent areas
   in skins may have to be adjusted accordingly.

   Update August 11th, 2008: A new background tinting option in the confi-
   guration dialog can help with recreating the previous appearance of un-
   modified skins when using translucency.

  ------------------------------------------------------------------------

Q: The terminal display corrupts in odd ways when I scroll. Anything I can
   do?

A: This is often caused by using compositing with an older version of the
   nVidia proprietary graphics driver, which has a known rendering bug with
   Qt 4 scrollviews on an ARGB visual. nVidia fixed the problem in version
   169.07 of the driver.

   Terminal display corruption may also occur when using compositing and Qt
   4.4 Beta 1. It is presently unclear if this problem will persist until
   the final release of Qt 4.4. In the meantime, a workaround for this pro-
   blem was added to the development version of the KDE 4 kdebase module on
   March 10th, 2008. Depending on how the situation develops, this work-
   around may be included with KDE 4.1 and possibly backported to a 4.0.x
   release.

   Update August 19th, 2008: This problem continues to affect Yakuake and
   Konsole in KDE 4.1 and with the final Qt 4.4 release. As a workaround,
   exporting QT_USE_NATIVE_WINDOWS=1 in the environment to disable window-
   less widgets in Qt prevents the problem from occuring at the cost of
   increasing flickering during window resize back to KDE/Qt 3 levels. The
   issue is still under investigation in cooperation with Trolltech/Nokia.