Cygwin is latest contributor on XFree86.org that gets pushed away by the behavior of some of its founding members and the dysfunctionality of XFree86.org. Hopefully, Red Hat, SuSE, FreeBSD, Apple, Sun and others will create a fork (or join Xouvert, X2 or a more ‘open’ X11.org) in a way that allows truly open development and innovation in X in a faster pace than XFree86’s maintainers have allowed so far.
Cygwin/XFree86 Abandons XFree86.org
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Well I have been mailing with Jim Gettys and some other people about this stuff – and even Havoc Pennington recently in an Article spoke about the same thing. They all don’t really belive that Xouvert developers have the balls to handle this task correctly in short timeframe.
Right now we have this issue:
– XFree who have been throwing out a lot of powerful people who wanted to fix all sorts of issues, put new good technology into XFree. What remains right now is slow development, old stuff in XFree itself like outdated fontconfig, xcursors, freetype2 and things like that and a bunch of bugs which were known for many months but which they ignore to fix. Look at that link:
http://pdx.freedesktop.org/pipermail/xlibs/2003-October/000004.html
– Then we have the Xouvert people who do a honourable job but whom real experts are worried whether they can deal with all this complex stuff or not
– And last but not least Jim Gettys’ and Keith Packard’s last bastion freedesktop.org (yes I hate to say this..) but that’s the place where old experts who develop on XFree for 12 years and longer to fix all the outstanding issues.
http://www.freedesktop.org/Software/xlibs
http://www.freedesktop.org/Software/xserver
…. now where will all this go ? Years back we were able to take the stuff from one center repository http://www.xfree.org compile and install it and we were sure that most of the stuff works out of the box. Today we deal with 3 different repositories which all have similar goals but still different things they do. We have good skilled people working on the freedesktop repository because they have no other place to do the work and their changes are hardly be put back into the core XFree CVS.
… well … I have no idea where this all will go. I’m a bit frustrated because the XFree CVS has this nasty Lock issue which let’s GTK+ HEAD crash in a continous way
http://bugzilla.gnome.org/show_bug.cgi?id=118436
Known for many months but NOT yet fixed in XFree’s CVS and XFree 4.4 or something is on it’s way to be released pretty soon.
I believe the same, Xouvert doesn’t seem to have the corporate backing and support, neither too many coders who can _really_ help in system programming.
I still believe that a new fork (or join a *modified organizationally and targetly* X11.org), between the BIG companies I mentioned and others, should come together and do X _right_.
maybe the major distro makers such are Redhat/Fedora, Mandrake, SuSE, etc… will make their own fork of xfree86 that can and will be better…
I may be a bit naive (spelling) on this, but is there any reason why someone can’t create a forked version of XFree86 and simple call it, XFree86-enhanced or what ever? I see that fontconfig etc are out dated, how hard is it to drop the current code in to it? setup a SF CVS and allow people to commit to it and merge XFree86 with the “enhanced” version when it does major releases etc etc.. I am not a developer so I my be talking crap, but it seems clear to me that XFree86 should be forked.
it already is – 3 times by the sounds of it. what a frikin mess.
we need somebody with real CLOUT to come along and bring the developers together who want to work on a single XFree fork. Having forks all over the shop doesn’t sound like a good idea for a system component as fundmental as this.
the question then, is who is a big enough character to lead a single, successful, XFree fork?
Earthworm: I guess thats more or less what I meant to post. Why the different forks and why not join efforts..
>>>>>>>>>>>>>>>>>&g t;>>>>>>>>>>>>>>>>>
Had he intended otherwise he could have easily said, “Gotta wait until the next board meeting”, or “Sorry, server died, gonna have to wait a couple days”. I can only interpret his ignoring the issue as a passive refusal to grant Cygwin/XFree86 CVS commit access.
>>>>>>>>>>>>>>>>>&g t;>>>>>>>>>>>>>>>>>
They did…
>>>>>>>>>>>>>>>>>&g t;>>>>>>>>>>>>>>>>>
http://www.xfree86.org
[27 October 2003]
The XFree86 services, including anonymous ftp, anonymous CVS, and cvsweb, that were unavailable for the past two days because of hardware failure have now been restored. Thanks go to the folks at ISC for working through the weekend to get a substitute server in place and running.
>>>>>>>>>>>>>>>>>&g t;>>>>>>>>>>>>>>>>>
I hope these companies the article mentions will get together and will bring an open XFree-based server that can drive innovation and Unix/Linux to new levels. It is in the hands of these corporations, because X is a huge project and hacker-style hobbyists efforts will fail as graphics companies don’t like sharing their specs without NDAs and without agreements.
“- Then we have the Xouvert people who do a honourable job but whom real experts are worried whether they can deal with all this complex stuff or not ”
Well if they are doing a good job, don’t you think the “real experts” – as you said – should join the project and help push it forward !!
despite the move to a modular backend in XFree86 4, X drivers are completely X-centric. This makes it impossible for the alternatives, such as Fresco (http://fresco.org/), Microwindows (http://www.microwindows.org), or PicoGUI (http://picogui.org/) to support a large variety of hardware, without using something like the SNAP graphics architecture which still precludes 3D support.
I think one of the great failings of XFree86 as an open source project is that the interdependancies of various portions of the codebase are too excessive to permit proper modularization of the project, due in part to the project’s server-centric architecture. Because it is so hard to break down X development work, it becomes impossible for anyone besides an enormous regulatory body to maintain the code.
I would like to see more support for XCB (http://freedesktop.org/Software/xcb), an attempt at reworking xlib to expose a better API to programmers, and for toolkits to be proactively modernized to support new X extensions at their fullest. I would also like to see an effort to revamp the X11 wire protocol, eliminating the legacy core graphics operations in an effort to see extensions like XRender (and other WIPs like Cairo) used pro-actively as standard protocol facilities. Toolkits like GTK and Qt do not properly abstract or utilize many X facilities, namely the XRender extension (which they use like a crutch when they see fit), or even the shared memory pixmap extension.
XFree86 is simply a mess, from a design, implementation, and organization perspective. Unfortunately it’s a mess I don’t see being cleaned up any time in the near future.
One major distribution, one major desktop environment and some dedicated people would give you a well integrated X11 replacement. When was the last time that X11 incorporated a change that made a big significant difference for desktop users? I couldn’t name any in recent history.
I think that freedesktop.org’s X server will win out in the end. And I mean in the end, because it may be some time. Seems like it’s mostly a re-write based on Keith’s kdrive.
For further reading:
http://x2.freedesktop.org/mailman/listinfo
When was the last time that X11 incorporated a change that made a big significant difference for desktop users?
Well, “X11” hasn’t been revised at all in recent history. However, if you’re talking about XFree86, the answer is…
Xv, which replaced DGA. Applications utilizing DGA, especially for hardware instead of software overlays, where a pain to use. It seemed relatively hard, especially when using hardware overlays, for application programmers to keep the overlay in sync with a moving/resizing window, which lead to a considerable amount of screen corruption and usage difficulty by the end user.
“the question then, is who is a big enough character to lead a single, successful, XFree fork?”
What about Bill Gates? Since Longhorn is due in 3 years, he should have some time on his hands
Seriously now. I hope all these discussions etc. lead to a more stable, more modern, more configurable, more compatible X like thing. I really do. I might be able to finally get my Ati Radeon 9000 working…
… one of the things that annoys me most about Linux/FreeBSD. Hopefully, they’ll do away with it sooner or later and replace it with something that doesn’t suck.
History has proven that it is impossible to get idealistic, totally clean changes made to legacy products. Such attempts almost invariably fail. Hence, DirectX has 5 version of API compatibility built in; the GDI is still there even though GDI+ has been available for years; Win16 support is still in the latest versions of XP; etc. The best anyone can do introduce new functionality in a clean a manner as possible, and hope that applications will move to take advantage of it.
I don’t see this being a problem at all for X. To answer HAL’s question, I have to point out fontconfig, XRender, Xft, and DRI as all being very user visible changes incorporated into X. And all of these technologies have been embraced by the major toolkits, specifically GTK+ and Qt. To respond to Bascule: its true that some recent extensions like Cairo and XRender have not been fully incorporated by the toolkits yet, but you have to realize that these technologies are not really usable yet. Both are almost completely lacking in hardware support, and are highly unoptimized. XRender, for example, is only useful at this point for alpha-blending glyphs, which is what the toolkits use it for. For anything else, the performance is terrible compared to mature, well-optimized client-side libraries like LibArt and Imlib.
As for the design of X, it is really quite modular. That was one of the big goals of 4.x. The major problem is that the source tree is extremely monolithic and nearly impossible to figure out. For example, XFree 4.x drivers are highly modular, with a very well-defined ABI between driver and server. Yet, Xouvert still has to do a lot of work to rip those drivers out of the source tree.
A more realistic list of goals for X would be the following:
1) As planned by Xouvert, modularize the source tree.
2) As a result of (1) it might be possible to then make a server-independent driver layer, so projects like Fresco could utilize X drivers.
3) Complete XRender and Cairo, and get hardware acceleration on a few key (ATI & NVIDIA) graphics cards.
4) Address any long-standing problems with useful extensions like MIT-SHM.
The toolkits would have to do some work too:
1) Abstract more X functionality. It might be wise to do this through an X abstraction library like GDK. This would allow projects like KDE to work towards removing direct X dependencies.
2) Once XRender and Cairo are usable, add appropriate canvas and image libraries based on them, and mark the old ones as depricated. You cannot simply base the existing canvas and image libraries on XRender and Cairo because the rendering models are so different. Even Microsoft couldn’t do GDI+ without making it a seperate API.
3) Work towards replacing xlib calls with something like XCB. This should be doable, because both of the major toolkits (GTK+ and Qt) are designed to be portable.
100% backwards compatibility should be maintained, because it is a prequisite for wide adoption. Applications and toolkits that do not use the new functionality should be considered “legacy”, and the project should not worry about them except to ensure compatibility.
I suggest OSNews readers to read the wiki from the xwin.org
website. http://x2.cs.pdx.edu/tiki/tiki-index.php?page=xwin
They speak about following things
Projects – Active projects for the betterment of X.
Wanton Desires – Things you just want X to do or have so much
and in your mind are achievable with mere human effort…
Blue Sky Dreams – Things that are a long way into the future,
or are just “out there”
Dumb Ideas – (aka X-Myths) Dumping ground for the
misconceived suggestions that infest any X discussion
Why would Redhat, Sun, or anyone else care about one developer having a hissy fit about CVS access? It won’t make any difference whatsoever in the great scheme of things. This Harold certainly knew the kind of crusty old people he was dealing with and only made himself look foolish by throwing a fit. Sure, he has a right to fork it if he wants, but why not act like a professional about it? His behavior sure doesn’t evoke any sympathy in me.
Please convince me that network transparency doesn’t take its toll on latency and responsivness, or don’t those count for the “slow” or are you just thinking about throughput.
Would it be easier to code a more straight-forward GUI rendering system that didn’t have all the network protocols? I don’t really know that much about how X actually renders the windows.
Please convince me that network transparency doesn’t take its toll on latency and responsivness, or don’t those count for the “slow” or are you just thinking about throughput.
I’m not sure how the moniker “network transparency” got applied to what it did. X provides mechanisms for local transport, most notably the MIT-SHM extension. Any client/server based window system will also require a wire protocol for whatever underlying IPC mechanism is being used. The only means of circumventing this is by placing the “server” in kernel context and using system calls to communicate between the userland process and the kernel “server”.
Deviation from a wire protocol comes in the form of a client rendering directly to a raster context (similar to Quartz’s approach). The disadvantage to this approach is that it’s very memory intensive.
Really, using a shared memory context to transport raster elements to a server where they are composited isn’t a bad approach, and certainly isn’t “network transparent”, although a 100% socket-based method is available as a fallback.
X’s main problem tends to be problems utilizing the shared memory extension when it is available, both by the toolkits and end-user applications. Usage of the shared memory extension is not 100% abstracted by the toolkits. KDE, for example, has written their own code on top of Qt to ensure utilization of shared memory when it is available.
The easiest way to lose the ‘X is slow’ mindset is this…
Get an old box, say a Pentium 133, with pretty much any gfx card. Install Slackware, and a wm, say Windowmaker.
Compile and install the browser ‘dillo’.
Browse the web, scroll through pages.
Fast, isn’t it? No rippling of text while scrolling, and windows maximise, drag and restore instantly.
Now start Mozilla.
Dog slow, isn’t it? Now, both applications are using Xfree, but one is fast, the other slow.
It’s easy to assume that apps are perfectly optimised, and X is the bottleneck, but in practice there is much work to be done on the apps themselves.
(Not that Xfree is perfect, but I think you have look at the bigger picture, using pre-empt+low latency kernel ‘improves’ X more than hacking out the network code would IMHO)
Couldn’t some one just take the code and make a new XFree86 project that is community controlled? Is that wrong?
Honestly, it is pointless to try to convince you. The X developers know a whole lot more about this than either you or I, and almost nobody in a position to know has come to the conclusion that network-transparency results in a loss of performance.
That aside, I’ll try anyway.
You are right that the client/server link introduces some latency. That latency is the time difference between the time the server notices an event and the time the application can act on it. With a good scheduler, that latency is about 2x as great as the latency of a mechanism where the app read events directly from a personal queue. Since these times are both on the order of a couple of milliseconds, the 2x latency increase is nothing that a user would notice as a lack of responsiveness.
Now, in the other direction, there is also latency between the time an app requests that something be drawn to the screen and the time it appears on the screen. In theory, this is extremely high on X over a direct-rendering model. However, that matters very little, because human beings don’t have fast reaction times. If the new image of a button takes 50ms to get updated on a mouse-over, the user will never notice. In fact, in Aqua (for example) there is an intrinsic delay of tens of milliseconds at this end because the screen image doesn’t change until the compositor gets around to blending the new image, which only happens at 30-50 fps.
The real bottlenecks in X have to do with synchronization and intelligent redraw. The first is made more complex by the client/server model, but is not inherently made impossible. The latter is entirely up to the apps, and is the most noticible thing. If a window displays a white border between the (non-white) contents and the frame as it is resized, the user will notice the effect no matter how fast you do the redraw. Human response times are slow, but the visual system is incredibly attuned to such changes. So even in the fastest window systems, you have to be smart about these things. This is very noticible in KDE today. Qt is well-optimized, so even complex Qt windows display excellent redraw behavior. KDE apps that mainly consist of Qt widgets display similarly good behavior. KDE apps that require complex custom logic for redraw (for example, Konqueror’s KHTML view) don’t perform as well.
Lastly, I have to point out that fast client/server GUIs have been implemented. BeOS and QNX’s Photon are both client/server (the latter moreso than even X: it makes the graphics driver a user-space server rather than a loadable module). Those GUIs are tons faster than any of the major ones available on OS X, Windows, or Linux.
Addendum to my last post: There is little practical difference between a client/server and networked GUI. Once a system is client/server, its a small step to make it networked. It simply involves sending the client/server protocol data over a network link.
There is little practical difference between a client/server and networked GUI. Once a system is client/server, its a small step to make it networked. It simply involves sending the client/server protocol data over a network link.
This is the point I was trying to make, although there are notable exceptions where this isn’t the case (e.g. Quartz)
The real bottlenecks in X have to do with synchronization and intelligent redraw. The first is made more complex by the client/server model, but is not inherently made impossible. The latter is entirely up to the apps, and is the most noticible thing. If a window displays a white border between the (non-white) contents and the frame as it is resized, the user will notice the effect no matter how fast you do the redraw. Human response times are slow, but the visual system is incredibly attuned to such changes. So even in the fastest window systems, you have to be smart about these things. This is very noticible in KDE today. Qt is well-optimized, so even complex Qt windows display excellent redraw behavior. KDE apps that mainly consist of Qt widgets display similarly good behavior. KDE apps that require complex custom logic for redraw (for example, Konqueror’s KHTML view) don’t perform as well.
In a modern window system I see no reason why a window should ever receive an expose event unless it’s being resized. Contents of windows should be buffered intelligently by the server
I know Y project is still very infant, one-man-show, no corporate support, student project, blah, blah. But at least it brought new ideas worth looking at..
seems that the current trend is just move away from Xfree86 and just complain about everything. If there were some HW problems that prevent any cvs management I wonder how they could add cvs commit right to the Cygwin people.
Fully double-buffering all windows is one of those hard design decisions. On one hand, it does enable faster redraw in situations where windows are exposed but their contents don’t change. However, it does nothing when windows are resized. On modern hardware, I tend to find that the latter is the bigger bottleneck, not the former. And I don’t like the idea of devoting all that memory (main RAM and the much more precious video RAM) to double-buffered windows. I also don’t like the impact managing all that data will have on the CPU cache. I guess we’re half-way there already though — most GTK+ and Qt widgets are already double-buffered.
A much more appealing idea to me is caching the vector-graphical representation of the window. Thus, when a window was exposed, the server could do the redraw without involving the client. The vector representation, of course, would consume much less memory. However, I don’t think this would be fast enough until we get full hardware acceleration of 2D vector graphics ala Longhorn or EVAS.
You’re right that X could make better use of the backing store and avoid some expose events, but that said there are actually cases where we want even more expose events. A case in point is handling transparent windows – we’d like to generate expose events for windows (or at least areas of windows) which are not at the top of the window stack.
I looked into the possibility of designing a vector based window system as part of one of my previous jobs. The idea is sound in some areas, but not others. There are large parts of an application that are not suitable for handling as reusable/resizable vector elements (you don’t want bigger text when you make a text field bigger for example). On the other hand, there are parts of the system where resizing vector objects (given appropriate size hinting etc.) can work well. A halfway house is something like NeWS where you can have server side code associated with a window, but this leads to other potential issues (such as the possibility of a malicious application exhausting server side CPU) and adds a lot of complexity.
GNU/Linux, FreeBSD, *NIX in general has a problem with a lack of a application framework. A blueprint that guides the development at different levels. The kernels and device modules are pretty cohesive, however – if device modules were set up at the bottom of the framework using a common device structure then their could be some progress upwards after that. As it stands the framework is fractured and not modularized (both at the same time!) Some one should work on a plan for a blueprint rather than focusing on one aspect and working on their piece of the puzzle. It is like a group of individuals working on their own little puzzles from a big pile of puzzle pieces from various puzzles, hoping that when all of the pieces are gone their large mishap sections will somehow fit together.
What you’re looking for is something like Qt + KDE’s application frameworks or GNOME’s application frameworks. Both are very powerful, and pretty comparable to what you’d find on Windows or MacOS.
Let me explain better what i meant to say:
Please convince me that xfree86 network transparency model doesn’t take its toll on latency and responsivness, or don’t those count for the “slow” or are you just thinking about throughput.
And this is especially true if you consider xfree’s monothreaded nature.
Well, the overriding proof is that many X developers have taken a look at it, and found that it is not the bottleneck. Not through speculation, but by actually analyzing program traces.
So the onus is on you to prove why you believe that X’s network transparency model is a bottleneck, given that there is no theoretical overhead to network transparency and no one has thus far observed that overhead in the current implementation.
There are, of course, ways of writing fast or slow X code, and those ways are shaped by its network transparent nature, but that’s the case for every window system.
For all those clamoring for unification and all what not, this what happens when you allow one project to dominate a culture. Xfree has been dissappointing of late, but we all stuck with it. They claim it’s an open development environment, but frankly, I don’t see what is open about it. Because your mailing lists are open doesn’t mean you practice openness.
If people find it hard to commit patches, if people’s suggestions are thrown to the bin, if people’s patches are rejected solely for political reasons, if there are not documentations or they are hard to find and hard to read, you might as well call it a closed source project.
If anyone one of you possess the coding skills or any other skills, including ranting, or feel like contributing to to a new X revolution, please have a look at the Y project. http://www.doc.ic.ac.uk/~mbt99/Y/ . There are two great and also easy to read documentations on the project. You don’t have be a Software engineer to understand them.
http://www.doc.ic.ac.uk/~mbt99/Y/report/MarkThomasPresentation.pdf <– Presentation 600KB PDF
http://www.doc.ic.ac.uk/~mbt99/Y/report/MarkThomas.pdf <– Report 1.71MB PDF
It’s about time we start telling Xfree to go screw themsleves. Too much power and over reliance is open soufce is bad. The entry barrier to joining and developing in Xfree is just too high. While Xfree is the best windowing system out there and has been for the last decade or so, I think it’s monopoly position is getting to it. If we had as many Windowing systems as we had DEs or Window managers, I’m sure this retardedness wouldn’t exist with regards to the State of Windowing Systems in Unix.
What the hell? We have to hack this to get anti-aliased fonts. Hack that to get alpha-blending. Hack the other to get transperency. Hack…hack…hack, when a modern windowing system should support this natively. Like I said, Xfree is the best windowing system out there but it’s becoming antiquated because the entry barrier to developing for the project has be artificially hicked and it doesn’t seem to me like an open development. Besides, that we need more Windowing Systems. We can’t just rely on Xfree.
I’m not talking about throughput.
Suppose you have multiple xfree86 clients, each client is generating events, responding to events or simply waiting for events over a socket, now, since the server itself is not multithreaded (i.e. one thread per connection) how can it guarantee each client consistent latency times? This is a classic example for using multithreading.
Sorry ’bout that. Accidentally hit submit: Disregard the previous post. Now for the response:
I’m not talking about throughput.
>>>>>
Neither am I.
how can it guarantee each client consistent latency times?
>>>>>>
Because most X requests have very predictable timing patterns.
This is a classic example for using multithreading.
>>>>>>>
A multithreaded X server has been tried and was found to be useless. This was mainly due to excessive contention for the rendering engine lock. Until we get SGI-style virtualized GPUs, this the graphics accelerator will prevent efficient use of a multithreaded server. See KeithP’s paper on X11 scheduler performance at: http://keithp.com/~keithp/talks/usenix2000/smart.html
This was posted in the Gentoo forums earlier. Apparently the source is the Xfree86 Wiki–though I don’t know exactly how official it is.
“This is a preliminary list of things planned for XFree86 5.0. It was originally posted to the forum mailing list (please check MailingLists).
These features require a lot of work. If you would like to help please take a look at the DevelopmentPages.
1. Redesign of XAB, so that multiple depth pixmaps can be stored in offscreen memory and the creation of a new directive – called the XAASurface. There will undoubtably be driver work involved to port to the new interface. The technical lead on this is Mark Vojkovich. I believe Mark has a substantial portion of this done, if not all.
2. FBManager extensions. This still needs further thought to encompass the requirements of all bases, but, the DRI is one that needs much more flexible memory management of the framebuffer. Secondly, it’s been requested before for linear allocation, rather than the current area allocation code for some Xv implementations.
3. Xlib locale removal. By removing all the Xlc code from libX11 and see if we can layer it on top of iconv. Need to discuss the advantages and disadvantages of such a task.
4. DGA – do we leave in, or do we shelve it ?
5. RandR. We now have rotation support, but not depth switching yet. This still needs to be done.
6. PseudoColor emulation. Egbert Eich has written some preliminary code for this, and we’re hoping he’ll be able to release it soon.
7. Hot Plugging of devices. Displays, Keyboards, Mice. This is obviously tricky when running multiple Xservers on the same machine. How do you correlate which device is plugged in, to which Xserver etc.
8. Multiseat capability. Allowing multiple Xservers to run with independent graphics cards, keyboards and mice on the same machine.
9. Xc/Xr – A postscript rendering library for the RENDER extension replacing Xlib drawing routines.
10. Window translucency.
11. XFixes extension.
12. Gamma corrected RENDER
13. Potential DIX/DDX changes. ”
All of these things, if implemented within a reasonable timeframe, would make me believe in the continuing vitality of Xfree86. Here’s hoping.
I think we all would heavily benefit if these guys would start fixing the bugs which they got patches for. Specially fixes that are urgently required to use GTK/GNOME and QT/KDE apps normally again without having them crash whenever touching due to the LOCK garbage in xlib.
I don’t know about that. Personally, I use XFree 4.3.99 snapshot 15 (the latest) and nothing really crashes. Maybe it’s Gentoo patches, though.
Xlib is something that needs to go. It’s huge, unwieldy, and is the source of many bottlenecks. Maybe de-localizing it is a start (though in any case, I’m talking out of my ass; I know nothing about X programming).
Please read the very first comment within this Article then you know about the bugs.
X doesn’t use the tcp/ip protocols then you are using it on localhost. So the network rendering isn’t a problem.
The link that you point out says the bug is already fixed (and has been for more than a week). What’s your point?
The bug has been fixed in the FreeDesktop’s Keith Packard & Jim Gettys very own repository and NOT in the real XFree CVS.
If you have followed my first reply carefully then you would have understood that there are THREE (in numbers 3) different own repositories. The FreeDesktop stuff is far from being usable in a normal environment. So what usage do I have when the stuff is fixed in someones private playground while the real repository won’t have that FIX ? Jim Gettys already forwarded the patches to the XFree team but until now they haven’t put these fixes in their crappy repository.
John Smith. The Multi-Threaded X Server. The X Resource, 1:73-89, Winter 1992.
Couldn’t really find much info on it, anyway it’s been a long time since 1992, what scheduler was used back then? and on what OS and hardware? what kind of threading? Directfb for example is multi-threaded, although i don’t really know if it provides concurrent access to surfaces. I think that Beos appserver was also multithreaded, not really sure about windows or QT embedded.
I think that Beos appserver was also multithreaded, not really sure about windows or QT embedded.
Yes, app_server creates a new thread for each window on the system, and another thread handles compositing. You can read about it here:
http://www.beatjapan.org/mirror/www.be.com/users/iconworld/icon4.ht…
1992 was a long time ago, but the situation probably hasn’t changed fundementally. Multithreading serves two distinct purposes:
– Allows for more even division of work
– Allows for utilization of a concurrent resource
The main issue is that the framebuffer is not a concurrent resource. Thus, there must be a lock around it to make sure that only one app at a time tries to draw to it. So the only use of threading in the GUI is to ensure even division of work.
BeOS did this in two ways. For each window, it created a thread in the app_server to handle requests from apps. This way, the OS scheduler naturally divided up the server-side work from multiple clients. Also, each BWindow ran in its own thread on the client side. Thus, when the app was sent a repaint message, the window would redraw as soon as the BWindow thread was scheduled, even if the main application was busy with something else.
X handles these problems in different, but equally valid ways. Instead of having a dedicated thread for each client, X has a scheduler that evenly allocated server time to processing requests from each client. To solve the second problem, X apps use various techniques (like non blocking I/O) to make sure that the application responds to repaints in a reasonable amount of time.
Now, one of the traditional weaknesses of X apps is that most were not very well coded, and did not respond to repaint events quickly. For example, early versions of Galeon would freeze up while a web page was being loaded into new tab. This has nothing to do with X, but a general (sometimes valid) fear of multithreading. More recent X apps (especially KDE and GNOME apps) use other mechanisms to quickly respond to redraw events, so this isn’t much of a problem anymore.
I was reading the thread where all the confusion started… jesus, you can’t believe how silly these guys are. They let the guy leave the project just because they didn’t want to give him CVS commit privilegies! Jesus!
I hope XFree will die. This project sucks, and it’s just holding back the “Linux Desktop” dream.
Victor.
The main issue is that the framebuffer is not a concurrent resource.
That’s when you use thread synchronization.
Without multithreading how does the server manage to properly share resources? without it, i’m guessing that if the server is doing something, lets say drawing a line, then it doesn’t do anything else until it’s done (until it completely draw the line. With threading you can simply switch threads even if one isn’t done. Of course this leads you to some problems regading occlusion, but if Beos and directfb can manage those then i can’t see any reason why xfree couldn’t also.
I think it’s unfair to blame the apps on something that really souldn’t be their responsibility (event handling).
let me explain this a bit better, i was thinking on per surface lock (i.e. each app would have one or more surfaces)