'Re: Review Request: Support for transparent panel without composition'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Review Request: Support for transparent panel without composition
From:       "Rob Scheepmaker" <r.scheepmaker () student ! utwente ! nl>
Date:       2009-03-30 15:33:16
Message-ID: 20090330153316.11241.11675 () localhost
[Download RAW message or body]

-----------------------------------------------------------
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
> 
> 

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[prev in list] [next in list] [prev in thread] [next in thread] 