On Mon, 15 Jul 2002, Lukas Molzberger wrote: >> > Hello, >> > in recent years many people were talking about Linux on the desktop. >> > However, before there is any real chance that this could happen a few >> > fundamential problems in XFree must be solved. These are: >> > >> > 1. XFree is far too slow. >> >> No it isn't. Your apps are stupid or the drivers you are using >> are under accelerated. > >I'm using Mozilla for example and I'm sure that its not that app that is slow >here since I've compared it with Mozilla on WinXP.
Comparing Mozilla running in X, and Mozilla running in Windows, and seeing that Mozilla running in X is much slower than it running in Windows, is totally not an indicator that X is slow. Zero scientific data has been gathered, and an incorrect conclusion made. Mozilla is faster in Windows, because the development of Mozilla in Windows has funded optimizing it to be faster. Some optimization work of Mozilla in X has been done, but nowhere near as far as the amount of optimization done to the Windows version. So comparing this is apples and oranges. Mozilla is slow in X because of Mozilla, not because of X. >It may well be that the driver is under accelerated. I'm the >i810 driver, but my old notebook with an smi chip was even >slower. I know that the Nvidia driver is much faster but as far >as I know the 2D part is still slower than under Windows even so >it actually uses the same driver. And none of those things have anything to do with X11 protocol getting in the way, or X being complicated. If a video driver is slow, then it is slow. X isn't slow, the video driver is. Solution is to make the driver faster, by improving it, or funding it, or conning someone else into doing either. What makes you think rewriting a new GUI would not encounter these problems as well? Someone has to write drivers, and if an X driver is slow, then likely new-GUI-of-the-week driver for that video card will likely be slow also. In fact, I would wager that that new-GUI will have most of it's driver code directly lifted from X, since there isn't much point in writing such code 100% from scratch. >> > 2. What is presented on the screen should always be consistent (i.e. no >> > flickering). >> > (3. It should be possible to configure XFree over a dialog that is >> > intergrated in Gnome and Kde.) >> >> Talk to the Gnome and KDE people then. > >True, but they can only change the XFree config file. Therefore XFree needs to >be restarted to get the new configuration. That isn't something that cannot be overcome by an X extension for many things. What's more, is that systems like Microsoft Windows *still* force you to reboot after even the most seemingly simple change to configuration. The joke "Windows has detected that you have moved your mouse. Your system must now be restarted for the changes to take effect." comes to mind. >> > I'm sorry to say that and I really don't want to offend any people. But >> > I've hardly seen any progress regarding these problems during the last >> > two years and I don't see any way how this could change in the next two >> > years. XFree is evolving very slowly despite the fact that some of the >> > best developers are working on it. I think the reason for that is that >> > XFree is far more complex than necessary for its intended job. >> >> You say it's too complex and then you say we need more features? > >I mean it has too much unnecessary complexety. I mean if the message system is >only needed for the remote display feature then I'm really not sure if this >feature is really worth the hassle. I've worked on two projects that >contained an message system and in both cases it was a major problem that ate >up a large chunk of the development time and it made the projects slow even >if used on the same machine. Some method of communication is necessary. What do you propose as an alternative solution? Any solution should be network transparent. We live in the world of networking now, and that is likely to get moreso in the future. VNC and other solutions are an afterthought solution for adding networkability to GUI systems. They work and have their good points, but they aren't a 100% solution for networked GUI applications. X11 is a much better solution. >> X is highly extensible by design. It's far less complex than >> alternative window systems like MS Windows or OS-X and is probably more >> extensible. >I actually think that extensibility is a very good idea, but it doesn't >prevent that API's age. What part of the X11 API are you refering to which is now aged and irrelevant. Also, how does that particular item negatively effect current development, current software, or present barriers to new developers to enter into the foray of development? I can't think of any part of X11 et al which stands in the way of progress. Extensions which themselves have become irrelevant and obsolete, have been deprecated. ie: XIE and PEX. They are no longer built by default, however their existance on a system or not, does not make learning X more or less difficult. Don't need XIE or PEX? Don't read their documentation, or use them. If they're not used, then they pose no negative aspect on the system at all. So I don't at all see the point of your "age" argument. Should some new GUI be designed every 5 years and the existing GUI of the time thrown out, because it is now 5 years old? That is what it sounds like you're advocating. Doesn't make much sense if the existing system works well and is easily extensible to add new features as needed. >> > 2d graphics drivers in users space while the 3d drivers are in kernel >> > space? >> >> You are mistaken. 3D drivers are not in kernel space. OpenGL is in >> user space in every OS I can think of. >I'm pretty sure there is 3D driver part in kernel space. And I think it would >be a good idea to also put the 2D part there. For example to have access to >the interrupts. Again, you're "pretty sure" but wrong. The 3D driver code and the 2D driver code are in userland. There is the DRI, of which the kernel portion is the DRM. The DRM allows userland video driver code to do DMA to the video hardware. ALL of the driver code itself is in userland. No, it is not a good idea to put it in the kernel. And as stated in a previous message, the Radeon driver is one which takes advantage of the DRM interface for both 2D and 3D when DRI is enabled. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
