mirror of
https://bitbucket.org/smil3y/kde-extraapps.git
synced 2025-02-24 10:52:53 +00:00
72 lines
3.7 KiB
Text
72 lines
3.7 KiB
Text
|
|
Yakuake KDE 4 FAQ (Last update: March 7th, 2011)
|
|
==================================================
|
|
|
|
Q: The open/retract animation is very jerky for me. Why is that?
|
|
|
|
A: First of, Yakuake currently employs two entirely different animation
|
|
strategies depending on user settings and the environment it is run
|
|
in. By default, when running in a KDE Plasma workspace v4.6 or newer
|
|
that has OpenGL Desktop Effects (i.e., compositing) and specifically
|
|
the "Slide" effect enabled, Yakuake will ask KDE's window manager to
|
|
perform the animation on its behalf. There are currently no known
|
|
performance problems with this animation strategy.
|
|
|
|
When Yakuake is run in an older version of the KDE Plasma workspace,
|
|
a KDE Plasma workspace with Desktop Effects or the "Slide" effect dis-
|
|
abled (or set to use XRender instead of OpenGL), or outside a KDE
|
|
Plasma workspace, it will fall back to the older animation strategy of
|
|
progressively adjusting (growing or shrinking) the window's mask and
|
|
moving the title bar along the mask's lower edge to simulate movement.
|
|
It will also fall back to this strategy when the user explicitly dis-
|
|
ables the window manager-assisted animation strategy in the configura-
|
|
tion dialog.
|
|
|
|
This older animation strategy appears to have performance problems
|
|
in combination with older versions of the proprietary nVidia graphics
|
|
driver, especially when the terminal is set to use a bitmap font and
|
|
font anti-aliasing is disabled. Oddly, despite anti-aliasing not
|
|
being applicable to bitmap fonts, enabling anti-aliasing seems to
|
|
improve performance (probably because it changes the driver-internal
|
|
code path for glyph blending or memory management), as does switching
|
|
to a scalable font like DejaVu Sans Mono.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
Q: The terminal display corrupts in odd ways when I scroll. Anything I can
|
|
do?
|
|
|
|
A: This is usually caused by using compositing (aka "Desktop Effects") with
|
|
an older version of the proprietary nVidia 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.
|
|
|
|
If a fixed driver is not available for your hardware or you are having
|
|
this problem despite not using nVidia hardware or their proprietary dri-
|
|
vers, exporting QT_USE_NATIVE_WINDOWS=1 has been known to help some
|
|
users. This comes at the cost of increasing flickering during window re-
|
|
size operations as it disables the use of windowless widgets in Qt.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
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, or the background tinting
|
|
option in the configuration dialog can be used to compensate.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
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: KWin's Shadow effect currently doesn't paint shadows for shaped windows
|
|
(aka windows with a "mask") for performance reasons. This is unlikely
|
|
to change in the near future. To compensate Yakuake may introduce sup-
|
|
port for shadows in skins in the future, similar to what Plasma already
|
|
does today.
|