Review Request: Support for transparent panel without composition

Alexis Ménard menard at kde.org
Mon Mar 30 21:32:47 CEST 2009 

On Mon, Mar 30, 2009 at 6:13 PM, David Nolden
<zwabel+reviewboard at gmail.com<zwabel%2Breviewboard at gmail.com>
> wrote:

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

That is not completly true. With composition we let the graphics card do it
for us. We fill the background transparent that is all.

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

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.

But thanks for your contribution.


>
> - 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 at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20090330/50f31afd/attachment-0001.htm

More information about the Plasma-devel mailing list