Review Request: Support for transparent panel without composition

[Rob Scheepmaker]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/472/#review729
-----------------------------------------------------------


Keeping this all within the desktop shell is a clear improvement over 'contaminating' libplasma, though I'm still not a big fan of supporting fake transparency. Realize, that with somewhat decent drivers, real transparency through compositing is most likely faster then fake transparency. It's designed for that sort of thing, just like moving a window in front of another window is also faster with compositing on, because the other window doesn't continuously need to repaint. Of course compositing had it's problem, which used to make compositing quite slower in practice, but nowadays, I can't really say I can notice any performance difference between using compositing and not, except a slight increase in memory usage, and a slightly warmer gfx card. So the 'snappy desktop' argument is not really valid imo. The only reason why you would want fake transparency is old hardware (not even low end, a lot of modern low end hardware handles compositing just fine) and/or crappy drivers. The crappy drivers part: one of the things I like about plasma is that it doesn't hack around problems in the software stack below it, it exposes those problems, and forces the stack below to improve, which benefits much more then just plasma. So that keeps people with old hardware as primary target for this patch. And really: if you really care about eye candy, why not spend 20 bucks on a new low end gfx card that handles compositing smoothly?
It also doesn't really decrease the amount of work that goes inside creating a theme significantly, because there's still quite some stuff that NEEDS an opaque version, like the dialog graphics (Plasma::Dialogs usually appear in front of other windows, so using fake transparency would be a really bad idea there), and extender items (needed for creating the pixmap used while dragging an item around). And having a fake transparent panel combined with a opaque plasma dialog connected to it would look..... a bit odd imo.

So long story short I personally think the advantages are too few to be worth introducing this hack into plasma. But if enough people think otherwise, feel free to ignore my opinion...

- Rob


On 2009-03-30 06:37:48, David Nolden wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/472/
> -----------------------------------------------------------
> 
> (Updated 2009-03-30 06:37:48)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> -------
> 
> Many people can not, or do not want to use composition. A semi-transparent panel highly increases the appeal of a Desktop, and there currently is only very few plasma themes available that have a nice-looking panel without transparency enabled.
> 
> All other major linux Desktop-Environments support transparent panels without composition(KDE 3.x, GNOME, and others), and since usually the only thing that needs to be visible through the panel is the Desktop itself, using a composition-less approach does not have much disadvantage here.
> 
> Here's I'm proposing a patch to achieve  this in a relatively clean way: The panel is painted and updated as if it was a plasmoid on the Desktop itself, grabbing the painted area plasma-internally directly from the  underlying desktop-view. The corresponding area of the panel is updated whenever the desktop is repainted, which means that animated plasmoids partially hidden under the panel, animations like the desktop-fading, moving plasmoids partially under the panel, etc. "just work".
> 
> Result: A nice looking panel for everyone, less work for theme designers. Please don't leave those behind who don't want or can not use desktop composition!
> 
> (Note: If you try this out, it doesn't work with all themes, since some themes seem to have no alpha-information in the non-composition case).
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdebase/workspace/plasma/containments/panel/panel.h 940781 
>   trunk/KDE/kdebase/workspace/plasma/containments/panel/panel.cpp 940781 
>   trunk/KDE/kdebase/workspace/plasma/shells/desktop/desktopview.h 940781 
>   trunk/KDE/kdebase/workspace/plasma/shells/desktop/desktopview.cpp 940781 
>   trunk/KDE/kdebase/workspace/plasma/shells/desktop/panelview.h 940781 
>   trunk/KDE/kdebase/workspace/plasma/shells/desktop/panelview.cpp 940781 
>   trunk/KDE/kdebase/workspace/plasma/shells/desktop/plasmaapp.h 940781 
>   trunk/KDE/kdebase/workspace/plasma/shells/desktop/plasmaapp.cpp 940781 
> 
> Diff: http://reviewboard.kde.org/r/472/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> David
> 
>