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