Review Request: Support for transparent panel without composition

[Alexis Ménard]

On Mon, Mar 30, 2009 at 9:15 PM, David Nolden <zwabel at googlemail.com> wrote:

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


Put a QDebug and look how many times you enter in the paint event of the
DesktopView. A lot! Lot of thing happen into the desktop even if the painter
is clipped you end up into the paintEvent anyway and do your intersection. I
agree that is not an expensive op but still it think that is overhead for a
feature that doesn't affect most of users now.


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


Yep but let's say you update the rect under the K Menu, you will repaint the
K Menu (because of update(), so it include the icon too), this things will
not happen with the compositing since the icon of KMenu is opaque. As I said
it not a big deal but it is not sexy.


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


We care, we just think that it is not useful to support that. Supporting,
maintaining and adding a "workaround" for a feature that is already provided
by the compositing is not relevant i think. Let's use what we have now and
let's behind us workarounds that we had for KDE3.
In KDE3 time we didn't have that, so those kind of workarounds was the only
solution.


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

Nice looking with actual technologies. It is very current that a game is not
with full details because you graphics card X doesn't provide the Y
functionnality. Same here.


>
> Sorry, but I find this attitude disappointing.


We just give our point of view.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20090330/24db4319/attachment.htm