[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Review Request: Support for transparent panel without composition
From: Alexis_Ménard <menard () kde ! org>
Date: 2009-03-30 21:06:32
Message-ID: 81941aea0903301406g40ba508ag6be6ca9af76caef8 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Mar 30, 2009 at 9:15 PM, David Nolden <zwabel@googlemail.com> wrote=
:
> Am Montag 30 M=E4rz 2009 21:32:47 schrieb Alexis M=E9nard:
> > That is not completly true. With composition we let the graphics card d=
o
> 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 th=
e
> > 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 updatin=
g
> > 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 painte=
r
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 th=
e
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 sai=
d
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 devic=
es
> > (those that don't have compositing).
>
> Who cares how future devices will be? Who cares how future drivers will b=
e?
> 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 h=
ow
> 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 provide=
d
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 plasm=
a
> 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 no=
t
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.
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Mon, Mar 30, 2009 at 9:15 PM, David Nolden <span \
dir="ltr"><<a href="mailto:zwabel@googlemail.com">zwabel@googlemail.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;"> Am Montag 30 März 2009 21:32:47 \
schrieb Alexis Ménard:<br> <div class="im">> That is not completly true. With \
composition we let the graphics card do it<br> > for us. We fill the background \
transparent that is all.<br> </div>You don't do that for plasmoids, do you?<br>
<div class="im"></div> </blockquote><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;"> </blockquote><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>
> In your case at each paintEvent on the panel you will end up to grab the<br>
> widget behind, create a pixmap, then blend each pixels with the panel<br>
> itself. Those are not free operations, especially on a device (we want<br>
> Plasma running on that too). So on those devices that don't have<br>
> compositing, we don't want by default that option. Then you have the<br>
> overhead in DesktopView::paintEvent() to check if you should invalidate and<br>
> call a repaint on the panel. I think it is overhead because most of the<br>
> paint event the check will be useless. So then solutions, cache the pixmap<br>
> which is blended and don't do the check change into paintEvent of the<br>
> DesktopView. But what happened there? Kickoff 2.0, when we should<br>
> invalidate the cache? When we should repaint?.... I forgot that updating<br>
> the whole panel like you do will end up to paint all applets in the panel,<br>
> even if there are cached they will be mark as dirty, for example the K Menu<br>
> will be repaint even if it don't need it (not transparent).<br>
</div>Since the background of the panel usually only consists of the wallpaper, \
this<br> should be a cheap operation, essentially not much different from what<br>
QGraphicsVIew does internall when it renders a plasmoid on top of the<br>
background.<br>
<br>
The overhead to check for intersection with panel is extremely small, not even<br>
worth noting. It's done per-event, not per-pixel.</blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> <br>
Not the whole panel is updated, only the part of it that intersects with the<br>
changed background part, so that part of your criticism is wrong. Please read<br>
the patch more exactly.</blockquote><div><br>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.<br> \
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> <div class="im"><br>
> So i think i will follow aaron and i think that is not an optimal idea. For<br>
> two reasons, Linux start to have proper drivers, and it's going to be<br>
> better every day, Gallium3D start to be supported by the industry (for the<br>
> future). More and more distributions come with packages that have<br>
> composition enabled and proper drivers. The second reason as i said is<br>
> devices, that will not help us to make Plasma + QGV fast on those devices<br>
> (those that don't have compositing).<br>
<br>
</div>Who cares how future devices will be? Who cares how future drivers will be? \
We<br> are already working on KDE 4.3, something that is called "stable" \
for public<br> use, right now! Why doesn't even a single plasma developer seem to \
care how<br> current or even past devices work?</blockquote><div><br>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.<br> In KDE3 time we didn't have that, so those \
kind of workarounds was the only solution.<br> </div><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;"> Do you expect everyone to dump his computer<br>
just to get a nice looking Desktop? Or are you planning to position plasma as<br>
a desktop-shell only for new computers, aka. Vista for Linux?<br>
</blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;"> <br>
Sorry, but I find this attitude disappointing.</blockquote><div><br>We just give our \
point of view. <br></div></div><br>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic