<br><br><div class="gmail_quote">On Mon, Mar 30, 2009 at 6:13 PM, David Nolden <span dir="ltr"><<a href="mailto:zwabel%2Breviewboard@gmail.com">zwabel+reviewboard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
<br>
> On 2009-03-30 08:33:22, Rob Scheepmaker wrote:<br>
</div><div class="im">> > 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?<br>
> > 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.<br>
> ><br>
> > 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...<br>
><br>
</div><div class="im">> David Nolden wrote:<br>
> 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.<br>
><br>
> Also, games are much slower just when enabling the composition in the xorg.conf.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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?<br>
><br>
> 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 ;-)<br>
<br>
</div>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<br>
<font color="#888888"></font></blockquote><div><br>That is not completly true. With composition we let the graphics card do it for us. We fill the background transparent that is all. <br><br>In your case at each paintEvent on the panel you will end up to grab the widget behind, create a pixmap, then blend each pixels with the panel itself. Those are not free operations, especially on a device (we want Plasma running on that too). So on those devices that don't have compositing, we don't want by default that option. Then you have the overhead in DesktopView::paintEvent() to check if you should invalidate and call a repaint on the panel. I think it is overhead because most of the paint event the check will be useless. So then solutions, cache the pixmap which is blended and don't do the check change into paintEvent of the DesktopView. But what happened there? Kickoff 2.0, when we should invalidate the cache? When we should repaint?.... I forgot that updating the whole panel like you do will end up to paint all applets in the panel, even if there are cached they will be mark as dirty, for example the K Menu will be repaint even if it don't need it (not transparent).<br>
<br>So i think i will follow aaron and i think that is not an optimal idea. For two reasons, Linux start to have proper drivers, and it's going to be better every day, Gallium3D start to be supported by the industry (for the future). More and more distributions come with packages that have composition enabled and proper drivers. The second reason as i said is devices, that will not help us to make Plasma + QGV fast on those devices (those that don't have compositing). One other points is devices start now to have openGL support and let's the graphics card do the job (faster, and the card will be smarter to optimize those operations). It is not a very slow operation but it is still some code to run, to maintain for a feature that will be honnestly pointless in 6 month or perhaps already.<br>
<br>But thanks for your contribution.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888"><br>
<br>
- David<br>
</font><div class="im"><br>
<br>
-----------------------------------------------------------<br>
This is an automatically generated e-mail. To reply, visit:<br>
<a href="http://reviewboard.kde.org/r/472/#review729" target="_blank">http://reviewboard.kde.org/r/472/#review729</a><br>
-----------------------------------------------------------<br>
<br>
<br>
</div><div><div></div><div class="h5">On 2009-03-30 06:37:48, David Nolden wrote:<br>
><br>
> -----------------------------------------------------------<br>
> This is an automatically generated e-mail. To reply, visit:<br>
> <a href="http://reviewboard.kde.org/r/472/" target="_blank">http://reviewboard.kde.org/r/472/</a><br>
> -----------------------------------------------------------<br>
><br>
> (Updated 2009-03-30 06:37:48)<br>
><br>
><br>
> Review request for Plasma.<br>
><br>
><br>
> Summary<br>
> -------<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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".<br>
><br>
> 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!<br>
><br>
> (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).<br>
><br>
><br>
> Diffs<br>
> -----<br>
><br>
> trunk/KDE/kdebase/workspace/plasma/containments/panel/panel.h 940781<br>
> trunk/KDE/kdebase/workspace/plasma/containments/panel/panel.cpp 940781<br>
> trunk/KDE/kdebase/workspace/plasma/shells/desktop/desktopview.h 940781<br>
> trunk/KDE/kdebase/workspace/plasma/shells/desktop/desktopview.cpp 940781<br>
> trunk/KDE/kdebase/workspace/plasma/shells/desktop/panelview.h 940781<br>
> trunk/KDE/kdebase/workspace/plasma/shells/desktop/panelview.cpp 940781<br>
> trunk/KDE/kdebase/workspace/plasma/shells/desktop/plasmaapp.h 940781<br>
> trunk/KDE/kdebase/workspace/plasma/shells/desktop/plasmaapp.cpp 940781<br>
><br>
> Diff: <a href="http://reviewboard.kde.org/r/472/diff" target="_blank">http://reviewboard.kde.org/r/472/diff</a><br>
><br>
><br>
> Testing<br>
> -------<br>
><br>
><br>
> Thanks,<br>
><br>
> David<br>
><br>
><br>
<br>
_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
</div></div></blockquote></div><br>