Review Request: Support for transparent panel without composition

[David Nolden]

Am Montag 30 März 2009 21:32:47 schrieb Alexis Ménard:
> That is not completly true. With composition we let the graphics card do it
> for us. We fill the background transparent that is all.
You don't do that for plasmoids, do you?

> 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).
Since the background of the panel usually only consists of the wallpaper, this 
should be a cheap operation, essentially not much different from what 
QGraphicsVIew does internall when it renders a plasmoid on top of the 
background.

The overhead to check for intersection with panel is extremely small, not even 
worth noting. It's done per-event, not per-pixel.

Not the whole panel is updated, only the part of it that intersects with the 
changed background part, so that part of your criticism is wrong. Please read 
the patch more exactly.

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

Who cares how future devices will be? Who cares how future drivers will be? We 
are already working on KDE 4.3, something that is called "stable" for public 
use, right now! Why doesn't even a single plasma developer seem to care how 
current or even past devices work? Do you expect everyone to dump his computer 
just to get a nice looking Desktop? Or are you planning to position plasma as 
a desktop-shell only for new computers, aka. Vista for Linux?

Sorry, but I find this attitude disappointing.