> 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 > > _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
