'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 17:26:32
Message-ID: 20090330172632.13934.73115 () localhost
[Download RAW message or body]

> 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 ;-) 
> David Nolden wrote:
> 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

Which nvidia driver version are you using? 180.35 work really well with my 8400 GS. \
I'm not saying there are no problems with compositing at all at the moment, there are \
people that have performance issues. But i'd rather see those issues solved in the \
stack below us. See for example the changelogs of the nvidia drivers: a lot of \
performance issues that KDE experienced with KDE 4, have been addressed by the nvidia \
developers, something that would never have happened, if we've worked around those \
problems in the first place. One of the design principles of plasma is to do things \
right, which often means offering less eyecandy to the composite-less. Your view that \
there will always be reasons not to use compositing is rather pessimistic imo. And \
about disabling compositing when power saving.... this is a valid use case but have \
you seen what for example the Plasma::Dialog looks like with glassified theme and \
compositing disabled? Just pop up the calendar and see what I mean. This just can't \
be changed. Themes like glassified are just not made to look very good without \
compositing. Fortunately there are themes that do look good without compositing.

- Rob

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

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