The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Qt on DirectFB
by whatever on Wednesday 27/Aug/2003, @07:36
|
>> All I wanted to get at is that having a window as a surface it becomes (new English word I guess) animationable.
'animatable'.. ;)
And yes, it would definitely make up for some very interesting effects when having the ability to apply xforms to windows or whatever.
I don't think XFree86 will ever be able to do that though.. (not even using cairo)
It's too old for that.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Nobody on Friday 29/Aug/2003, @04:06
|
So what if it becomes even more clear that X11 cannot handle tomorrow's desktops and there will be real need for OpenGL accellerated windowing system, what then?
Sure you might argue that there is no need right now, and sure that is partially true (well atleast I would love to be able to show off Linux desktop to my Apple and my friends using Apple) but should the Qt4/KDE4 to be designed for the future or for today's hardware and software requirements? I think the only right way for that is to plan to use pure OpenGL as everyone else (like Apple with their Quartz Extreme is doing right now and Longhorn is also going to use it) are and Linux community is going to need to get it done!
So is there any already evaluated windowing systems that might fit the bill? Sure there are some but they are on pretty alpha stage but should there be some chosen system that would surely get more attention in the future?
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tim Jansen on Friday 29/Aug/2003, @06:17
|
>>So what if it becomes even more clear that X11 cannot handle tomorrow's desktops and there will be real need for OpenGL accellerated windowing system, what then?<<
When did it become clear? X11 does not prevent you at all from using a MacOS X-like, OpenGL based rendering system, at least not at the application level. The apps still render their windows and get their events like they did in the last 20 years. They may use classic X11 functions, new X11 extensions like Cairo graphics or OpenGL over GLX, but they still use rectangular windows as primitives.
The window manager may need to be aware of such a composition system (obviously, current X11 can not transform windows), but not the apps. And even that could be done using a X11 extension, no need to replace X11.
I will never understand why people are so eager to throw away the X11 system, even though they have yet to show a feature that X11 could not do - the only problem are implementations, not the protocol.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by AC on Saturday 30/Aug/2003, @14:12
|
>>>>I will never understand why people are so eager to throw away the X11 system, even though they have yet to show a feature that X11 could not do - the only problem are implementations, not the protocol
I think this is related to the fact that not everybody understands how X is designed. Most people observe X is almost always causing troubles and causing literal headaches when setting up (refresh rate). Improving its setup procedure might remove most of the bitter experiences people now face with X.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tobias Hunger on Monday 01/Sep/2003, @09:43
|
Of course X does not prevent you from doing whatever you want. When you get down to it X is basically a blown up graphics driver. You can pile everything on top of that, you can do all desired effects, etc. Nobody is arguing that point.
But why would you want to? Why are you using languages like C++, Smalltalk or whatnot instead of Assembler? Because you don't want to be bothered with all the bit-pushing that's going on behind the scenes. The same is true with X windows: Who does actually develop for it nowadays? Nobody! All the developers are building their work on toolkits that could be run on any other graphics driver as well (probably better than on X, too:-) or on APIs better suited for their purposes like OpenGL, libArt or some SVG library.
Users don't care about the low level stuff, they still stick with X since all their applications happen to run on that 'driver'. If they switch to something else they are bound to loose some of their favorite applications.
Don't get me wrong: I do use X and I even like it a lot. It is a revolutionary product! But it is time to start to think about what could happen in the past-X(11R6) age. That could be something new like fresco (www.fresco.org) or picogui (www.picogui.org), it will most likely be X as we know it with some more extensions clobbered on or it could be DirectFB/Qt (I'd hate having that, networktransparency rocks) or something completely different!
Anyway, what made me post this is that I hate those "This is great and needs no fixing" attitude. Nothing is perfect, not even X. Why are you so rough to people trying to think out of the box? They could very well come up with some good ideas... which might result in some X successor, however that may look like.
I for one thing have a graphics card that has 10 times the clockspeed of my first PC's CPU. I payed for that power, I want it used. Of course I'd prefer something productive, but I'll settle for eye candy;-) If X can't do that - and as of today it can't - I'm looking for other projects and try to help those along.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tim Jansen on Monday 01/Sep/2003, @10:42
|
>>All the developers are building their work on toolkits that could be run on any other graphics driver as well (probably better than on X, too:-) or on APIs better suited for their purposes like OpenGL, libArt or some SVG library.<<
Toolkits are layers on top of X11, and there are good reasons for layering them. The most important ones, probably, are that a) layering increases flexibility and b) the relative simplicity of X11 makes things like NX possible. To use a analogy myself, an approach like Frisco is like improving HTTP by getting rid of TCP and writing an alternative that provides the functionality of HTTP over TCP.
If there is *functionality*, including eye candy, that can not be transported using X11 and its extensions, you could easily convince me that it is a good idea to work on a second protocol. But I don't see it a point as long as the user does not notice any difference except that the old applications don't work anymore. If you start the post-X11 era, you should have a compelling reason for this.
Integrating widgets on the server side in a way that's less flexible than DPS rather limits the capabilities of the window system than increases them. There are still, and always will be, applications that do not want your widget kit and provide their own. Examples are emulators like Wine, and apps that want their own widgets for eye candy reasons (games are the no 1 example, but just look how many Windows apps do not use the Windows widgets).
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tobias Hunger on Tuesday 02/Sep/2003, @00:45
|
>> Toolkits are layers on top of X11, and there are good reasons for layering them. <<
You are right. My point is that with every application depending on the top layer only, what stops you from even considering switching the bottom layer? That's exactly the increased flexibility you gain by layering! Why are you so much against someone even bringing up the topic?
>> To use a analogy myself, an approach like Frisco is like improving HTTP by getting rid of TCP and writing an alternative that provides the functionality of HTTP over TCP. <<
To stay in the layer-paradigm ou have brought up: Fresco is a set of interfaces defined on top of CORBA which in turn is a protocol defined on top of (among others) TCP/IP. So your analogy should be more like "improving HTTP by replacing it with something more powerful on top of SOAP on top of TCP." with SOAP and TCP being widely adopted standards.
>> If there is *functionality*, including eye candy, that can not be transported using X11 and its extensions, you could easily convince me [...] <<
Device independence, resolution independence, vector-based rendering, 3D capable desktop, and most important of all a consistent look and feel of applications, even while keeping the configurability we all know and love. Just to name a few...
Of course nobody is stopping you from adding all that to X via some extension. We decided not to work on an X extension for a simple reason: All X could do for us is access to the graphics card. We can get that in a more flexible way by using SDL/GGI/DirectFB/GLUT, some of them being able to run inside X or outside. The same is true for input devices. Network/language transparency? We get that for free from using CORBA, a technology necessary to have all the objects communicate (no, we will not replace CORBA, we need all it offers; no, something you need is not bloat; yes, CORBA is slower than sockets but because our architecture is way different from what X does that impacts performance far less then you might think; no, we cannot remove CORBA and replace it with something else). We need to do our own focus- and fonthandling, etc., so why on earth should we limit ourself to being an X extension? Fresco is less then 200K lines of code... why dock that onto a 2M lines of code XFree-monster for that little it offers to us? Right now that would hinder more then it would help.
Anyway: The important issue is that someone is trying out new things in free software and that the code is there. Take the code and turn it into an X extension if you think that's better than what we do. It doesen't matter to me what it is actually called and where it ends up getting used. What matters to me is that someone is experimenting.
>> [...] that it is a good idea to work on a second protocol. <<
We aren't. The protocol is defined by the OMG as part of CORBA and is called IOP. We just provide a set of interfaces on top of this protocol. That's not much different from what KDE and Trolltech do by providing their libraries using the X protocol.
>> If you start the post-X11 era, you should have a compelling reason for this. <<
No, you need a compelling reason not to want to improve on what is already known. The spirit of invention driving human development and all;-)
I am further not starting the post-X era, neither is anyone else in Fresco. We are just trying out some (not that new but still untried) ideas. But then who could claim more for those guys at MIT originally writing X? ;-)
>> Integrating widgets on the server side in a way that's less flexible than DPS rather limits the capabilities of the window system than increases them. <<
Correct. That's why we are not doing it.
>> There are still, and always will be, applications that do not want your widget kit and provide their own. <<
.. which of course they can in Fresco. We just try to discourage that as much as possible, just like Apple, Microsoft and probably KDE, too. And since our concept of a widget, being just some collection of graphics (like everything else on the screen) is way more flexible than the "each widget is a object with hardcoded attributes" used in traditional X toolkits, we are convinced that there is less need for custom widgets.
If you insist on using your own widgets you can, building them up from the same basic building blocks as the 'default' widgets. That is some work of course (not more then inheriting the basic functionality and extending it) and maybe someone will write up a "GUI painter" for that purpose someday... with the GUI consisting of the same elements as a graphics view that will be really easy. Well, there goes the consistency... ;-)
>> Examples are emulators like Wine, and apps that want their own widgets for eye candy reasons <<
The eye-candy reasons does not hold in Fresco:-) If a user wants eye candz he can just replace the admittedly ugly MotifKit with a (to be written) "Fully3DTexturizedMeshesWidgetKit" on his system and he will have eye candy widgets for all his applications. The look and feel can be freely changed by the *user* in Fresco (in X the developer selects the look and feel and might offer some themeability so that the user won't notice this too much;-), all Fresco does is making sure that all applications (that do use the normal interfaces to produce their widgets) look and feel the same.
>> (games are the no 1 example, but just look how many Windows apps do not use the Windows widgets) <<
I do not consider games a no 1 example: They tend to run fullscreen and need all the power the graphics card can deliver, so they usually go around the GUI environment as much as possible. So I don't see much need to discuss games in this context.
Some words about compatibility: You can extend X and you will end up with something else (let's call it Y for now). Anything written for Y won't run on X: backward compatibility is broken. Of course any X application will work on Y, too. That's great and a absolute must have if you ever want to think about replacing X.
But what about writting something (let's call it Fresco here) and implementing a X server in it? Any Fresco application won't work on X, but you could still run X apps on top of Fresco in the embedded X-server. So how does this differ from an extended X from a users point of view? That this is a feastable option was proven by Apple: It is what they have done with there MacOSX GUI.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tim Jansen on Tuesday 02/Sep/2003, @09:59
|
> My point is that with every application depending on the top
> layer only, what stops you from even considering switching the bottom
> layer?
There are many top layers that people do not want to miss. Toolkits like Qt, GTK and XUL are very different and the holy grail of widget theming is still to implement a widget style that runs at least on Qt and GTK. So do you want to support only one toolkit, modify at least one of their APIs enough that you can use a single widget implementation or try to write one that is so flexible that it works with both?
And, of course, beside regular toolkits there are other challenges like SDL, apps that use XLib directly for various reasons and statically linked binaries, especially for commercial apps.
> Why are you so much against someone even bringing up the topic?
Sorry, I just heard way too often that dropping X11 solves all problems. And I never saw any proposal (or even code) that solved more problems than it created.
> All X could do for us is access to the graphics card.
It would also offer a communication middleware that is very well known and analyzed, for example regarding performance issues. I don't think that such a amount of research has gone into any CORBA-based rendering system (or maybe even CORBA for applications with real-time characteristics).
> why dock that onto a 2M lines of code XFree-monster for that little it offers
> to us?
While I can understand detesting XFree's (or X.org's) prehistoric code base, it cumulates a lot of experience and code for using graphics hardware on hundreds of different architectures, and is the only widely used X11 implementation. If you want to implement any X11 emulation you would have an hard time to emulate X.org's exact behaviour.
Proprietary drivers for NVidia cards are also a showstopper for everything that does not use XFree's driver model (there is no chance to get people use an OpenGL-based system without NVidia support).
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by wup on Tuesday 02/Sep/2003, @01:37
|
You know what's the whole issue with XFree86?
IT IS TOO OLD AND NOT FLEXIBLE for todays standards (!)
Having said that, see the following comparison:
* setting resolution (@ runtime)
DFB: IDirectFB::SetVideoMode
XFree86: Use XRandr, depth cannot be set
* render an alpha blended rectangle
DFB: IDirectFBSurface::SetDrawingFlags, IDirectFBSurface::FillRectangle
XFree86: Use XRender (or Cairo, which usually uses XRender implicitly)
* getting an OpenGL surface for doing 3D graphics
DFB: IDirectFBSurface::GetGL
XFree86: Use a mix of GLX and X
* double or triple buffering of window surfaces
DFB: Automatic
XFree86: Backing store (b0rked, so not usable)
* documentation
DFB: Nice and easy
XFree86: Boring and hard to read/understand
* system integration
DFB: Boot kernel in graphical mode -> jump right into the desktop (nice!)
XFree86: Boot, mode switch, mode switch, mode switch, ... (ugly & unprofessional looking)
It's just the small things, but as you can see; one very important thing is that DirectFB can do things using a nice API without using yet another library/extension, thanks to the non-dependency on X11.
And not only that, it's also just too easy to create a slow GUI (that is, without Gtk or Qt, though even both these toolkits are still making some mistakes -> see perf docs from KP and that guy @ HP) using XFree86, which is partly the fault of X11 and partly the fault of XFree86 not being improved anymore (for the last few years (!)).
Another issue: the latest standards for eye candy (which is often very usable as well, not just for nice looks (ie. window drop shadows)) are very hard to do using XFree86 (nearly impossible without hacking away).
Using DirectFB it's much easier.. eg. I don't think it would be hard to create genie-like window effects using DFB.
Oh, and writing a driver for DirectFB is also a far more pleasing experience.
It's time for something fresh...
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by anon on Tuesday 02/Sep/2003, @06:39
|
write back when I can use my NV Gf4 at reasonable speeds on DFB
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tim Jansen on Tuesday 02/Sep/2003, @10:10
|
>IT IS TOO OLD AND NOT FLEXIBLE for todays standards.
Then the easiest solution is to improve it.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by wup on Tuesday 02/Sep/2003, @11:14
|
>> Then the easiest solution is to improve it.
Probably not, as no person or even group of coders has/have succeeded in doing that the last few years..
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tim Jansen on Tuesday 02/Sep/2003, @11:24
|
AFAIK no one tried. And by creating something from scratch things won't be easier, because you probably want more features than the 2 millions lines of code in XFree provide, not less.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tobias Hunger on Tuesday 09/Sep/2003, @07:56
|
It is easier to create something from scratch!
* You are not stuck to an stone-age (IT industry-wise) protocol
* You do not need to wade through heaps of code added for obsolete architectures
* You do not have to work with a display model that matched the hardware that was available over 10 years ago and needs all kinds of clutches to get adapted to modern 3D accelerator boards and such
* You get a clean set of interfaces instead of the extensions-mess we are seeing in X today with obsolete extensions being dragged through the releases and dozends of interfaces for basically the same functionality.
If throwing out 2 Mio. lines of working code scares you: Don't forget that the 2 Mio. lines of XFree code does include lots of rarely used clients, too which could go with no harm done to get replaced by KDE/Gnome apps providing the same functionality. Then throw out all those obsoleted extensions (only those marked as obsolete and those that never really worked anyway) and you get down to a surprisingly small SLOC count!
The only really interessting thing in XFree are the graphics drivers... and unfortunately those seem to be really hard to rip out due to heavy interdependencies with the rest of the code.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Bernd Gehrmann on Tuesday 09/Sep/2003, @23:43
|
> You are not stuck to an stone-age (IT industry-wise) protocol
Then I would suggest you to stop using Internet, which is using
a protocol that predates X11 by a decade. Oh, while you are at it,
you may also consider dropping BSD, Linux and other Unix-like
operating systems which are essentially technology of the
late 1960's :-)
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tobias Hunger on Wednesday 08/Oct/2003, @09:33
|
Networks got faster, sure, but the basic assumption of "shoving data in at one end and getting it out at the other" still holds.
Graphics hardware on the other hand went from "set a couple of its in some chunk of memory" to "Render a Mesh with a lamp setup at this position". With such a change of abstraction level something new might be in order, don't you think?
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Steve Keate on Thursday 15/Jan/2004, @02:30
|
"You know what's the whole issue with XFree86?
IT IS TOO OLD AND NOT FLEXIBLE for todays standards (!)"
This is EXACTLY the argument people use against Unix based OSes, and frankly it's a load of bullshit.
Mac OS X has lineage that can be traced directly back to the original AT&T Unix, historic BSD, and CMU Mach, yet few people would argue that it is not flexible enough for today's standards.
MS Windows is older than X11 (though some of X11's underpinning concepts predate Windows) yet few people would argue that Windows is not flexible enough for today's standards.
The actual limitations inherent in the X11 protocol are fewer than in most contemporary graphics systems since it is conceptually quite abstracted from the hardware, so in fact it's less likely that X11 is going to be fundamentally unsuitable for any type of graphics rendering than, say... Windows.
Mac OS X's Quartz window system uses many of the same ideas for network transparency as well as a fundamentally inefficient PDF based language to represent graphics, yet seems to do quite well for itself in both the performance and flexibility stakes, as evidenced by it's use of eye-candy so rich you want to floss your eyes after watching it for half an hour.
When pointing your finger, you'd do well to remember that there are four more pointing somewhere else.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by novice_root on Thursday 17/Aug/2006, @03:03
|
I totally agree with you. i just hope some day gnome and kde both will have a choice of running on either of X or DirectFB.
And with intel open sourcing its drivers i hope directfb gets the much needed hardware support.
|
[
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)
