> 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 > > Rob Scheepmaker wrote: > 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.
Exactly that version. I'm not saying it doesn't work good, But it still works a lot better without composition, and I'm not willing to get my usability significantly reduced just to get transparent krunner windows. The important stuff like a nicely looking desktop is also achievable without composition, and that's why I'm here. Actually I'm one of the relatively lucky guys: My Hardware _would_ do composition in a nearly acceptable way. But I'm also raising the voice for those who can not use composition, which probably is more then 50% of all current linux users. As I said, KDE4 is not a future technology, it's also a technology that is ment to be used _now_, so it has to work _now_. I think it's good that KDE pushes the technology, but I don't like that it happens by leaving users behind. Another thing: Consider a random new linux user, who doesn't have composition, doesn't know what it is, and doesn't even care. Now he tries to get a nicer plasma theme than aya, uses gethotnewstuff, and sees 18 out of 20 themes he downloads look like total crap. What an impression does that make? Just by the way I think we need to find a way to make composition-centric themes also look good without composition, because it seems like theme-designers just don't care about that case, and it's also quite a burden to them. They should just supply masks for non-composition, and that should be it. For example, either a user-configurable non-black solid color, the wallpaper, or another generic theme background pattern could be used as background, instead of black. Together with better automatic theme mask detection, this would make _all_ plasma themes look good even without composition. - 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 > > _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
