Re: [Xpert]Is the XFree development stuck in a dead end?
On Monday 15 July 2002 01:46, Mark Vojkovich wrote: > 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. 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. > > > 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. > > > 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. > > > I know there have been countless discussions on the X messaging system, > > but most of them missed the point. That is that such a messaging system > > introduces an enormous amount of complexity. As far as I know the only > > reason for having the X messaging system is the remote display feature. > > But I guess that less than 5% of the XFree users are actually using this > > feature and there are already other solutions like VNC available. > > Another source of complexity comes from the ancient, more than 10 years > > old X API. Many people argue that one just has to add new extensions to > > keep XFree up to date. But this way X gets more and more complex. And why > > are the > >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. > > > 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. > > > As a result of this complexity the developers working on XFree are less > > efficient and it also keeps new developers from joining this project. > > What I want to suggest is to start from scratch and design a new, clean > > and modern windowing system without any legacy. I know this would be a > > pretty radical cut, but I personally don't see any alternative to > > overcome the current problems of XFree. > > The main problem with a new graphics API would be to keep backward > > compatibility with the current application base. But this problem is easy > > to solve by just porting XFree to the new API, the way it is done for OS > > X and Windows. > >I think you have the wrong mailing list. XFree86 is an implementation > of the X-Window system. The key phrase here is "the X-Window System". > XFree86 is headed in the directions of an "X-Window compatible" system, > meaning we intend to extend XFree86 well beyond the base sample > implementation, and in many regards we have done this already, but we have > no intention of dropping what you call legacy support. > >As far as development being stuck, no, I don't think so. It's just > that the people who know enough about anything to get things done are > very few. True, but there are reasons for that. Cheers Lukas ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is the XFree development stuck in a dead end?
On Monday 15 July 2002 01:39, Nick Name wrote: > > 1. XFree is far too slow. > > I don't know what your terms of comparison are, but for example "return > to castle wolfenstein" on same hardware runs really faster than on > windows, with maximum settings. Dunno if this means anything. Sorry, I should've written clearer what I mean. Only the 2d performance of XFree is slow. For example XVideo Opengl are indeed very nice. I don't use WinXP for other reasons, but just compare it with XFree. I think the feeling is just so much better. I mean thats not a special XFree problem. I've worked on IRIX machines for a long time and there you have the same problem. I mean I know that it's not all XFrees fault. The Toolkits also play an important role. > > > 2. What is presented on the screen should always be consistent (i.e. > > no flickering). > > It is already? No, just move one Window over another or do an opaque window resize and you'll see artefacts all over the place. > > > (3. It should be possible to configure XFree over a dialog that is > > intergrated in Gnome and Kde.) > I would like to apologize in case I didn't find the right words. I just think there is a problem with XFree and don't see it going away anytime soon. Cheers Lukas ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Is the XFree development stuck in a dead end?
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. 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.) 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. I know there have been countless discussions on the X messaging system, but most of them missed the point. That is that such a messaging system introduces an enormous amount of complexity. As far as I know the only reason for having the X messaging system is the remote display feature. But I guess that less than 5% of the XFree users are actually using this feature and there are already other solutions like VNC available. Another source of complexity comes from the ancient, more than 10 years old X API. Many people argue that one just has to add new extensions to keep XFree up to date. But this way X gets more and more complex. And why are the 2d graphics drivers in users space while the 3d drivers are in kernel space? As a result of this complexity the developers working on XFree are less efficient and it also keeps new developers from joining this project. What I want to suggest is to start from scratch and design a new, clean and modern windowing system without any legacy. I know this would be a pretty radical cut, but I personally don't see any alternative to overcome the current problems of XFree. The main problem with a new graphics API would be to keep backward compatibility with the current application base. But this problem is easy to solve by just porting XFree to the new API, the way it is done for OS X and Windows. Cheers Lukas ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Slow opaque window resizing
On Tuesday 25 June 2002 18:32, Owen Taylor wrote: > Lukas Molzberger <[EMAIL PROTECTED]> writes: > > Hello, > > I'm using Linux and XFree for quite some time now and I'm a big fan of > > it. However, there is one bug that has always annoyed me. When I resize a > > window under XFree then it can take a long time until the content of this > > window is redrawn. > > I've also looked into the Mailing List archieves and found an discussion > > about this topic earlier, but it seemed to be without a result: > > http://www.xfree86.org/pipermail/render/2001-March/000829.html > > I think that it would be good to have this issue fixed for two reasons. > > First, it looks ugly and second, for many people resizing a window is a > > simple way of testing the performance of a new OS like Linux. > > I think what you are seeing is a known bug in the XFree86 scheduler: > > http://www.xfree86.org/pipermail/xpert/2001-August/010435.html > > Basically, what happens is that X sees: > > Window manager isn't taking much time to draw and is getting lots > of mouse events. > > Application is taking a lot time to draw and is getting no mouse events. Yes, I think that's exactly the problem. > > Decides that the application is a badly behaved client and starves it > out of existence. Running X with the -dumbSched command line option > should improve things a lot. OK, I'll try that. > > I talked about with this Keith at some point and he thought it > should be easy to fix, but I don't remember the details. > > Like many scheduling problems, it is, fundementally an architectural > problem. Ideally, the window manager should wait for the client before > processing the next step in the resize; but it's really hard to do > this with the Window manager / client separation in X. Is there really no way to let the window manager wait for the client? I mean, sure, you can improve the behavior by changing the scheduler, but I doubt that you can really fix the problem this way. Wouldn't it be possible to let the client application send an "finished drawing" event back to the WM? If that's not possible in X itself, would it make sense to implement a communication between the WM and the client completly outside the X server, for example through dcop? I know, that would also be just a hack since the problem would only be fixed for applications that support this. Cheers, Lukas ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Slow opaque window resizing
Hi Mark, thanks for your reply. On Tuesday 25 June 2002 03:27, Mark Vojkovich wrote: > On Fri, 21 Jun 2002, Lukas Molzberger wrote: > > Hello, > > I'm using Linux and XFree for quite some time now and I'm a big fan of > > it. However, there is one bug that has always annoyed me. When I resize a > > window under XFree then it can take a long time until the content of this > > window is redrawn. > > This has little to do with the X-server. Many window managers do not > optimize window resizes well (they aren't compressing the events) and > many clients do not handle exposures very well. That's possible and it might also be responsible for a part of resizing slowness, but I think that what Owen explained in his reply is exactly what I meant. > I don't think there's > much on the X-server side that can make up for that. > > > Another thing that I've noticed is that when moving a window from left to > > right or vice versa the window is split along a line and the upper part > > of the window is drawn at a slightly different position than the lower > > part. This splitting line is always at a different position. I think this > > happens because X doesn't synchronize with the horizontal screen refresh. > > X should wait until the screen refresh is finished before changing the > > frame buffer so that only a consistent picture is brought to the screen. > > In case I got something wrong here than I would like to apologize for it. > >Window moves shouldn't synchronize with the refresh rate because > of the performance penalty it would impose. All other rendering would > be suspended until the next retrace whenever you wanted to move a > window. Hmm, what I first thought about was to synchronize the double buffer swapping with the screen refresh, similar the way it is done in OpenGL. As far as I know most toolkits use double buffers and such a db swap is also very fast. However, I'm not sure if that would help when moving a window? But if window moves would be synchronized with the refresh rate why would all other rendering be suspended until the next retrace? I also don't think that there would be a large performance penalty, since the worst case delay time would only be 1/80 second. > This shearing effect can mostly be eliminated by sychronizing > your pointer sampling rate to the refresh rate. Just set you pointer > sample rate to 80 Hz and also your refresh rate to 80 Hz and you will > find that all mouse-driven operations will appear much smoother. OK, I'll try that. Thanks for the tip. > >Also, given that the X-server is a user-space app. Synchronizing > blits with the retrace is typically not possible on most hardware. > Cheers Lukas ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Slow opaque window resizing
Hello, I'm using Linux and XFree for quite some time now and I'm a big fan of it. However, there is one bug that has always annoyed me. When I resize a window under XFree then it can take a long time until the content of this window is redrawn. I've also looked into the Mailing List archieves and found an discussion about this topic earlier, but it seemed to be without a result: http://www.xfree86.org/pipermail/render/2001-March/000829.html I think that it would be good to have this issue fixed for two reasons. First, it looks ugly and second, for many people resizing a window is a simple way of testing the performance of a new OS like Linux. First I also thought that this is an performance problem but I've tested it on really fast hardware and that didn't make much difference. Now I've looked a little bit closer and noticed that it more kind of an synchronization problem between X, the WM and the App, than an performance problem. While resizing a window it's frame is redrawn at a very high rate. Only the window contents is redrawn very slowly. It sometimes even takes seconds to redraw. I think the problem is like this: First the window manager gets an event from the mouse and decides that the window needs to be resized. For every new mouse position it receives, the WM draws a new window decoration. At the same time the WM sends a message through X to the application that the window content needs to be refreshed. Unfortunately, the application needs more time to redraw than the WM and is also running at a lower priority. Therefore the application throws many redraw requests away. In my opinion, the solution would be that after the WM has send the redraw request to the application it should wait until the application has finished redrawing the window before processing the next mouse event. I had a look into the X api but I didn't figure out how the WM could detect if the redawing is finished or not. But it might be that I've overlooked it. One way of getting this information would be to let the WM and the application talk directly to each other, but I think that this would be a hack. I would have tried to come up with a patch on my own, but I really don't know enough about XFree to do that. Another thing that I've noticed is that when moving a window from left to right or vice versa the window is split along a line and the upper part of the window is drawn at a slightly different position than the lower part. This splitting line is always at a different position. I think this happens because X doesn't synchronize with the horizontal screen refresh. X should wait until the screen refresh is finished before changing the frame buffer so that only a consistent picture is brought to the screen. In case I got something wrong here than I would like to apologize for it. Cheers, Lukas ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Slow opaque window resizing
Hello, I'm using Linux and XFree for quite some time now and I'm a big fan of it. However, there is one bug that has always annoyed me. When I resize a window under XFree then it can take a long time until the content of this window is redrawn. I've also looked into the Mailing List archieves and found an discussion about this topic earlier, but it seemed to be without a result: http://www.xfree86.org/pipermail/render/2001-March/000829.html I think that it would be good to have this issue fixed for two reasons. First, it looks ugly and second, for many people resizing a window is a simple way of testing the performance of a new OS like Linux. First I also thought that this is an performance problem but I've tested it on really fast hardware and that didn't make much difference. Now I've looked a little bit closer and noticed that it more kind of an synchronization problem between X, the WM and the App, than an performance problem. While resizing a window it's frame is redrawn at a very high rate. Only the window contents is redrawn very slowly. It sometimes even takes seconds to redraw. I think the problem is like this: First the window manager gets an event from the mouse and decides that the window needs to be resized. For every new mouse position it receives, the WM draws a new window decoration. At the same time the WM sends a message through X to the application that the window content needs to be refreshed. Unfortunately, the application needs more time to redraw than the WM and is also running at a lower priority. Therefore the application throws many redraw requests away. In my opinion, the solution would be that after the WM has send the redraw request to the application it should wait until the application has finished redrawing the window before processing the next mouse event. I had a look into the X api but I didn't figure out how the WM could detect if the redawing is finished or not. But it might be that I've overlooked it. One way of getting this information would be to let the WM and the application talk directly to each other, but I think that this would be a hack. I would have tried to come up with a patch on my own, but I really don't know enough about XFree to do that. Another thing that I've noticed is that when moving a window from left to right or vice versa the window is split along a line and the upper part of the window is drawn at a slightly different position than the lower part. This splitting line is always at a different position. I think this happens because X doesn't synchronize with the horizontal screen refresh. X should wait until the screen refresh is finished before changing the frame buffer so that only a consistent picture is brought to the screen. In case I got something wrong here than I would like to apologize for it. Cheers, Lukas ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
