Description: ok guys, these days i'll work over a mac os x phanter with quartz extreme, and is awesome and fast and customizable. well i play ut 2003 amazing on my pII 333 with redhat 9 on my tnt 16Mb. and i think, we still can use X to handle a high core level with openGL with glut or whatever, my main idea is rewrite qt and kde to handle the entire graphic core, and before, work in the amazings stuffs like forms rendered and antiaaliased or forms with any shape form or a kwin animated or high definition openGL widget over the desktop,etc
if somebody wanna work with my, with this improvement goto http://sourceforge.net/projects/kdeextreme/
or send me an email at jrch99@cantv.net
Plataform Linux ;-) Language C++, C
i still working on the sourceforge page, if you cannot join send a mail
There's already a QT - OpenGL context called QGL, including QGLWidget, QGLColor, QGLContext and some others.
Of course, there's no KDE module I can find in a quick skim of my manuals...
Are you serious? Do you have any idea how huge that is? and how stupid it is also?
Making QT and KDE use opengl is not only the most pointless act of insanity possible but it is also the worst way of going about adding GL support.
1. Why do you think QT needs it? Because it's slow? because XFree's slow? No it's not. If you mean the speed of Render's compositing, then head on over to xouvert or xfree and help them out with standardizing a Render test suite so driver maintainers can get Render acceleration into their drivers. If you mean how _smooth_ redrawing is after expose events, then you should work WITH qt (note: not fork it) to work on double buffering (coming in qt4) and the ungrouping of expose events, as well as the ability to use X's backingstore.
2. Adding opengl support to QT isn't that hard anyway... all you basically have to do is modify the QWidget code to play opengl instead of X! (theres prolly some other places that may need to change, if there is any hacky code using the X primitives directly (does QPainter do this?)
Over all, I think you should have considered this before starting it, as using opengl to accelerate KDE and QT themselves will barely benefit the smoothness of the desktop. Also the speed improvements will be undeterminable (because drawing, the only part affected by opengl, is already too fast to see, and im talking DRAWING, not the speed of reaction to expose events)
these mockups are not right i just put it because the upload give me error if i dont out some images, as soon as posible i will put a really mockups
sorry
you are right, but Translucent handle GL low level graphic core, and this is very nice, but we are talking about to make the medium and highest api level from kde
of course we dont refuse the posibility to join the both project in a near future, when both have some stability
No it looks quite nice in my opinion. And just because you dont like how X development with Xfree works doesnt mean you should HACK it up.
besides, thats why xouvert exists
what happen to you bro, the x does not have any relation from opengl code in the core, infact the same code must work even in directfb or darwin.
i just mentioned the X as a reference because the X still have the largest 3d drivers support for linux, and nvidia works really fine like matrox and some ati cards too.
you are obviously pretty thick. KDE = X. Period. No question whatsoever.
As I said in a below comment, accelerating QT will do nothing for you. If we were to use opengl as a basis for a new rendering target in XFree86, then we could make things like alpha compositing and blitting and many other eye candy effects very fast and very easy
Ratings & Comments
12 Comments
http://www.kde-look.org/content/show.php?content=18790 http://www.kde-look.org/content/show.php?content=18983 GL widgetry tried any glscreensavers with --root option ? OpenGL is already all over the desktop, don't need a rewrite just have to work out a few minor ? bugs ?
There's already a QT - OpenGL context called QGL, including QGLWidget, QGLColor, QGLContext and some others. Of course, there's no KDE module I can find in a quick skim of my manuals...
Are you serious? Do you have any idea how huge that is? and how stupid it is also? Making QT and KDE use opengl is not only the most pointless act of insanity possible but it is also the worst way of going about adding GL support. 1. Why do you think QT needs it? Because it's slow? because XFree's slow? No it's not. If you mean the speed of Render's compositing, then head on over to xouvert or xfree and help them out with standardizing a Render test suite so driver maintainers can get Render acceleration into their drivers. If you mean how _smooth_ redrawing is after expose events, then you should work WITH qt (note: not fork it) to work on double buffering (coming in qt4) and the ungrouping of expose events, as well as the ability to use X's backingstore. 2. Adding opengl support to QT isn't that hard anyway... all you basically have to do is modify the QWidget code to play opengl instead of X! (theres prolly some other places that may need to change, if there is any hacky code using the X primitives directly (does QPainter do this?) Over all, I think you should have considered this before starting it, as using opengl to accelerate KDE and QT themselves will barely benefit the smoothness of the desktop. Also the speed improvements will be undeterminable (because drawing, the only part affected by opengl, is already too fast to see, and im talking DRAWING, not the speed of reaction to expose events)
also, what the hell is this a joke? those mockups are completely stupid.
these mockups are not right i just put it because the upload give me error if i dont out some images, as soon as posible i will put a really mockups sorry
Anyone interested in this idea might also be interested in TransluXent: http://www.stud.uni-karlsruhe.de/~unk6/transluxent/
you are right, but Translucent handle GL low level graphic core, and this is very nice, but we are talking about to make the medium and highest api level from kde of course we dont refuse the posibility to join the both project in a near future, when both have some stability
why not just wait for xfree 5?
XFree 5... which is due in .... ? My guess is that X's future is quite dark right now :-(
No it looks quite nice in my opinion. And just because you dont like how X development with Xfree works doesnt mean you should HACK it up. besides, thats why xouvert exists
what happen to you bro, the x does not have any relation from opengl code in the core, infact the same code must work even in directfb or darwin. i just mentioned the X as a reference because the X still have the largest 3d drivers support for linux, and nvidia works really fine like matrox and some ati cards too.
you are obviously pretty thick. KDE = X. Period. No question whatsoever. As I said in a below comment, accelerating QT will do nothing for you. If we were to use opengl as a basis for a new rendering target in XFree86, then we could make things like alpha compositing and blitting and many other eye candy effects very fast and very easy