faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Will KDE 4 eyecandy be fast?
by Troy Unrau on Wednesday 21/Mar/2007, @19:06
|
Actually, that video is showing off a feature I haven't yet talked about for KDE 4 (mostly because it hasn't been merged into trunk yet). It's using kwin_composite, a GL accelerated kwin which does the real transparency at the video card level.
I've briefly talked to the kwin_composite dude (Seli), and he informs me that it will make it into KDE 4.0, barring any unusual problems. It's a good solution for KDE to appeal to those wanting a pretty desktop (like Beryl), but at the same time it has a great fallback mechanism whereupon those without GL acceleration can use some effective software rendering, or have all effects turned off. Basically, it's all about adding bling, while maintaining KDE 3's level of performance (or actually improving it where possible).
When it merges into trunk, I'll feature it here :) |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Will KDE 4 eyecandy be fast?
by batonac on Wednesday 21/Mar/2007, @19:24
|
OK, so let me get this strait. The transparency in that video had nothing to do with the QT4? It was just done through a beryl/compiz like setup? If this is true, what is the advertised QT4 real-time transparency good for then?
|
[
Reply To This | View ]
|
Re: Will KDE 4 eyecandy be fast?
by Troy Unrau on Wednesday 21/Mar/2007, @19:35
|
Take a closer look - there are two transparencies happening:
One is showing a widget that you can see part of the background image from. It is shown off in the still screenshot I posted above, which does not use any beryl/compiz-style transparency. You will notice that the run dialogs' background is showing even in the line-edit. This is an application-internal type of transparency, possible because Qt controls the whole widget stack. It's quite slick...
But Qt doesn't control X, so when doing transparency between windows, X methods need to be used. This beryl/compiz like window tranparency is handled by kwin_composite and relies on Qt, GL, and the X Composite extensions. This video is not using beryl/compiz, but uses a similar implementation found in kwin_composite. It uses Qt for some effects (such as blurring/recolouring the background) and Qt-driven GL calls for others (such as wobbly windows, no demonstrated in the video) where appropriate.
|
[
Reply To This | View ]
|
Re: Will KDE 4 eyecandy be fast?
by batonac on Thursday 22/Mar/2007, @19:36
|
Hey thanks troy for keeping up with me, I understand now.
You gave me an idea though, we really should build an X replacement that's completely controlled by QT, a QT accelerated graphics display system for Linux, where QT can control all elements of the display, not just the internal parts of QT programs. That would be talking. Its unification like this that's needed in order for Linux to take over the desktop.
|
[
Reply To This | View ]
|
Re: Will KDE 4 eyecandy be fast?
by Frogstar Robot on Thursday 22/Mar/2007, @20:07
|
That's all well and good but what happens when I want to run a non-QT app? There are several here and there that are pretty good......
|
[
Reply To This | View ]
|
Re: Will KDE 4 eyecandy be fast?
by batonac on Saturday 24/Mar/2007, @14:31
|
A display system that supported only QT would force the KDE community to create KDE programs that provide ALL computing needs. This would be a good thing since it would provide complete unification of the Linux desktop. Think about it.. ALL programs would use the same file save and open dialogs. ALL programs would use the same color scheme/widget style. ALL parts of the display would be powered by the SAME graphics engine which means LESS CONFIGURATION and LESS CONFUSION. KDE taskbars should be able to have true real-time transparencies just through QT 4, but NO, in order to do this, we have to write additional 3d extensions to kwin which will be working IN ADDITION to the new QT Arthur paint engine, instead of being powered by it. Arthur is probably powerful enough to do this, but QT doesn't control X, so it can't be done. I'm really sick and tired of X windows actually. X doesn't have native SVG render support so all SVG used in QT programs have to be rendered and cached before they can be displayed by X. If the graphics system was controlled by QT, as QT would improve, so would the graphics system, new versions of QT wouldn't have to constantly maintain backwards compatibility with an out-of-date graphics system.
|
[
Reply To This | View ]
|
Re: Will KDE 4 eyecandy be fast?
by Vide on Sunday 25/Mar/2007, @07:49
|
Go buy a Mac, you really want one of those.
|
[
Reply To This | View ]
|
KDE should be better than Mac OS X
by batonac on Monday 26/Mar/2007, @10:02
|
Ha! You're probably right, I probably should just get a mac, but Mac OS isn't completely opensource. KDE Linux really should be a complete Mac OSX replacement, but currently, it doesn't quite cut it.
|
[
Reply To This | View ]
|
|
Re: Will KDE 4 eyecandy be fast?
by me on Thursday 22/Mar/2007, @17:15
|
Does the fallback include using 2d compositing/EXA? I much prefer this as it is, at least on my machine, considerably faster and nicer to look at than all that Beryl crap, which runs slow and looks dumb.
|
[
Reply To This | View ]
|
Re: Will KDE 4 eyecandy be fast?
by Troy Unrau on Friday 23/Mar/2007, @08:30
|
You'd have to ask Seli about who the fallback mechanism works in more details... or, once it's merged back into trunk, I'll do the research and write about it.
*puts on a fedora with a press card on the front*
|
[
Reply To This | View ]
|
KWin OpenGL fallback
by Duncan on Saturday 24/Mar/2007, @15:54
|
This subthread is of concern to me as well, as I've presently a now aging but until very recently "best freedomware 3D support available" ATI Radeon 9200 series card. The native xorg Radeon driver in merged framebuffer mode supports accelerated OpenGL on this thing up to 2048x2048, but I'm running two monitors at 1600x1200 resolution, stacked for 1600x2400, so there's 352 lines' resolution unaccelerated at the bottom of the combined display.
With KDE3 (3.5.6 currently, on Gentoo/amd64), running xorg (now the 7.3-rcs), I've found EXA works waaayyy better than XAA, with composite and composite effects (only the transparency, fading takes time, and shadows just don't add anything to my experience, maybe because I run light foreground on dark background by default, so I can't see them in many cases, unless I reversed them of course, which is just... weird) turned on. It works quite well, actually, with the single exception being OpenGL apps go blank when moved partially into that zone... not so great when that's my main work monitor. I'd hope that before the entire desktop goes OpenGL, xorg would kill that 2048 max height/width acceleration issue -- and of course the xinerama OpenGL accel issue if it still exists as well. That's not under KDE's control of course, but a decent fallback to 2D EXA would be fine, as long as it remains a viable option.
Of course, if there's one thing KDE two and three have been good at -- one of the main reasons it's my desktop of choice -- it's giving people reasonable options, and I'm reasonably sure that's going to continue with four as well. I'm just commenting here in the interest of ensuring it does. =8^)
BTW, here's a now dated (a bit over a year old, Feb 2006, KDE 3.5.1) screenshot (1/3 size). Astute KDE users will likely recognize the layout of the page as modified from one generated by the Konqueror Create Image Gallery tool. =8^)
http://members.cox.net/pu61ic.1inux.dunc4n/pix/screenshots/index.html
Duncan
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
