Bug 174490

Created attachment 28375 [details]
screenshot of problem

Unfortunately I'm unable to exactly understand your problem based on your screenshot, so I can only give you generic information.

Which parts of a skin feature translucency is determined by the PNG graphics files that the skin is made of. In the case of the default skin, translucency is features in the graphics that make up the tab bar area. The title bar area is intentionally opague.

Translucency requires an X server with COMPOSITE support, as well as a running compositing manager (such as the "Desktop Effects" feature in KDE 4's window manager).

Created attachment 28392 [details]
skin demonstrating the problem

Install it as usual through Appearance settings.

OK, let me rephrase.

The skin is split in two main areas. Top ("tabs", which contains the tabs and the new/close tab buttons) and bottom ("title", which contains the text and the focus/menu/quit buttons).

Now I use a theme that has transparent pngs for both top and bottom backgrounds. Top renders as expected (I get real transparency etc) while the bottom part is bugged. When I say bugged I mean that it almost never renders correctly.

Some times after I first start Yakuake, change the theme and apply, or just change the width (smaller or bigger doesn't matter) it draws correctly but after I do something of the above it gets corrupted.
Corruption includes parts of the previous contents of the bottom background. Looks like some buffer should be refreshed or emptied before redrawing.

I also noticed that it breaks even without transparency enabled in the options. Try disabling transparency and setting the background to a bright color such as red to see it better.

I am attaching the default theme, but edited making both "tabs" and "title" backgrounds completely transparent, so that you can test it.

Please download and install my attached theme to reproduce it. After installing and applying the theme try changing the width and you will see what I am talking about.

Just to make it clear: it isn't just transparency as I initially thought and it is ONLY the "title" area that has the problem.

Thanks.

Transparency for skin elements is currently only supported in the tab bar graphics, although I notice I forgot to mention that in in the skin creation readme file.

The reason is performance-related. The Yakuake open/hide animation works by adjusting the window's XShape mask to sequentially hide/unhide parts of it, and moving the title bar widget along with the lower edge of the mask to give the appearance of the window rolling in and out. In many environments (in terms of graphics drivers and 2D performance), the performance of moving the title bar widget on the window turned out to be only acceptable when setting the Qt::WA_OpaquePaintEvent render hint on it, which makes Qt disable widget content progagation and expect the widget to fully fill in itself.

There are a couple of options:
- Investigating whether the X world and Qt have progessed sufficiently to stop using Qt::WA_OpaquePaintEvent on the title bar widget. With the recent advancements in nVidia's XRender acceleration, this might be the case.

- Replace the current animation strategy with a more performant one. I would really like to move away from adjusting the XShape mask to moving the entire window contents within the window, relying on an alpha mask for clipping. This would be a lot smoother, but also has a set of problems: (1) It only works with a compositing manager, (2) Window shadows (Kwin in KDE 4 currently doesn't paint any shadows for shaped windows, but with the new animation strategy it wouldn't be shaped anymore during animation, and the window shadows wouldn't move with the perceived window edge), (3) Without a mask, clicks would still register on the fully transparent parts of the window during animation.

- Starting with Yakuake 2.9.4, Yakuake fills the window with the user-configured background color in cases, to give the option to tint translucent skin areas. However, this is done on the top-level window widget, and thus bypassed by the title bar widget's Qt::WA_OpaquePaintEvent render hint. This could be worked around by adding the pre-fill pass to the title bar widget as well.

Overall, option 3 seems like the most likely one at this point.

(Was supposed to be "in all cases" in the next-to-last paragraph.)

SVN commit 881105 by hein:

Remove the Qt::WA_OpaquePaintEvent render hint from the title
bar widget to investigate the performance impacts. Previously,
not using it would slow the animation down to a crawl in par-
ticular with the horrible XRender acceleration in older nVidia
drivers. If it still turns out to be unacceptable for too many
people, the background pre-fill pass from the top-level window
will have to be added to the title bar's paintEvent as well.
CCBUG:174490


 M  +0 -2      titlebar.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=881105

SVN commit 952438 by hein:

Add back this animation speed optimization avoid the
regression vs. 2.9.4; the impact of not doing this is
simply too great, even with Qt 4.5. Translucency in
title bar skins will likely be allowed once the win-
dow animation is rolled into a KWin Desktop Effect,
which should make it butter-smooth.
CCBUG:174490


 M  +8 -0      titlebar.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=952438

Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!