Review Request: Support for transparent panel without composition

David Nolden zwabel+reviewboard at gmail.com
Mon Mar 30 19:13:22 CEST 2009



> On 2009-03-30 08:33:22, Rob Scheepmaker wrote:
> > 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...
> 
> David Nolden wrote:
>     I have a geforce 9600GT, had a 7600GT before, am using the newest nvidia drivers. This is probably the best supported and close to the fastest hardware available for linux composition, still under high workloads(4 times make, 1 kdevelop parsing, 1 amarok), it feels extremely sluggish, and even without that workload it _always_ lags a few milliseconds. To you those milliseconds might not matter, but to me they do.
>     
>     Also, games are much slower just when enabling the composition in the xorg.conf.
>     
>     The only other hardware that right now supports composition in an acceptable way is probably the intel drivers, but those cards are usually also to slow to fire a full composited 3200x1200 Desktop. My old intel notebook had even too slow graphics to composite a 1024x768 Desktop in an even remotely acceptable way.
>     
>     I didn't even want to discuss about these issues, the key point is: There is _many_ reasons not to use composition, and many people who cannot use it. There probably always will be.
>     
>     Also, think for example about the KDE feature that shuts off composition when power is very low. How unbelievable ugly is it right now, when for example the glassified theme is used, and it shuts the composition off for you?
>     
>     The key point: Just because composition works for you does not mean it works for everyone. Also, you shouldn't tell people they need to buy new hardware, just so they can do something that there hardware is perfectly capable of(That is _that other OS_ style ;-)

Btw. with that patch, the panel is rendered in exactly the same way as a plasmoid, so if you think the performance is problematic, then you should equally worry about those


- David


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


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



More information about the Plasma-devel mailing list