Linux graphics handling is idiotic
Just a question about Xfree. If people are saying its slow and bloated because of extra things like network transparency and the such, why hasn''t anyone made a less bloated version? Something along the lines of a single user version, take out the network stuff and other things that a home user wouldn''t need. Is this even possible or is it just a matter of not enough man power or lack of interest to do it?
Hitchhiker90"There's one bitch in the world, one bitch with many faces" -- Jay"What are you people, on dope?" -- Mr. Hand
Would that even really be truly possible? Well, I''m sure it would be, but the extra work involved in getting it to work transparently with current X apps would probably sacrifice any extra speed you''d gain.
The Artist Formerly Known as CmndrM
http://chaos.webhop.org
The Artist Formerly Known as CmndrM
http://chaos.webhop.org
September 03, 2003 06:51 AM
How about this reason: OpenGL graphics will sometimes be displayed inside a window in X.
Exactly. Same thing with why, for example, NeHe''s tutorials utilize Win32 API code: You need a window somehow.
The Artist Formerly Known as CmndrM
http://chaos.webhop.org
The Artist Formerly Known as CmndrM
http://chaos.webhop.org
There is a very simple reason why eliminating network transparency in X just doesn''t make sense.
Any multi-application graphics system must have a controlling entity that assigns resources to applications, determines which input events go where, etc.
There are only two possible ways one can implement this controlling entity:
- as a kernel module; this is usually frowned upon because of system stability issues, among others
- as a user space process; this is the case with X windows
In the latter case, the graphics system must have a form of IPC.
XFree can use both TCP/IP and Unix domain sockets (+ shared memory) for IPC. When you''re running it locally, it uses the latter, which is the fastest form of IPC available - at least on Linux, I''m sure there are some micro kernels that can do faster IPC.
Since having TCP/IP support as well doesn''t hurt the local case in any way, there''s simply no reason to drop TCP/IP.
There is one part in the design of X that has timing/lag problems (not necessarily performance problems though), and unfortunately, this part is one of its greatest features. I''m talking about the window manager.
There are many cases where communication in X works like this or similar: Client -> X -> WM -> X -> Client
When more than one client is involved, this leads to a whole lot of problems, which is why the Inter-Client Communications Conventions Manual (ICCCM) exists.
It would be interesting to see an in-server window manager as a loadable module. This would still allow diversity while minimizing or even eliminating a lot of the ICCCM headaches. This is quite a major change, but if you feel like revolutionizing anything in this area, it''s probably the most productive thing you could try.
cu,
Prefect
Any multi-application graphics system must have a controlling entity that assigns resources to applications, determines which input events go where, etc.
There are only two possible ways one can implement this controlling entity:
- as a kernel module; this is usually frowned upon because of system stability issues, among others
- as a user space process; this is the case with X windows
In the latter case, the graphics system must have a form of IPC.
XFree can use both TCP/IP and Unix domain sockets (+ shared memory) for IPC. When you''re running it locally, it uses the latter, which is the fastest form of IPC available - at least on Linux, I''m sure there are some micro kernels that can do faster IPC.
Since having TCP/IP support as well doesn''t hurt the local case in any way, there''s simply no reason to drop TCP/IP.
There is one part in the design of X that has timing/lag problems (not necessarily performance problems though), and unfortunately, this part is one of its greatest features. I''m talking about the window manager.
There are many cases where communication in X works like this or similar: Client -> X -> WM -> X -> Client
When more than one client is involved, this leads to a whole lot of problems, which is why the Inter-Client Communications Conventions Manual (ICCCM) exists.
It would be interesting to see an in-server window manager as a loadable module. This would still allow diversity while minimizing or even eliminating a lot of the ICCCM headaches. This is quite a major change, but if you feel like revolutionizing anything in this area, it''s probably the most productive thing you could try.
cu,
Prefect
Widelands - laid back, free software strategy
Problems with X that people notice.
1) Lag because of the bouncing of the protocol and serial nature of most events. You can''t really get around "X -> client -> X" for things like clicking a button having that cause a new window to pop up. but as the previous poster noted, the WM type stuff IS unecessary, and needs to be redesigned, unfortunately, that mean X12, which nobody really wants to do.
2) Drivers. This is the huge, vast, cover-all-complaints problem with XFree86. "Nobody" notices the above problem since on local machines its blindingly fast. (and "nobody" uses the network stuff, right?) What they do notice is that quake 4 runs with 1 fps. The problem is that card manufacturers don''t like to write open source drivers for their cards.
3) Conventions. Ever wonder why your whole window needs to be redisplayed every time it moves? Yes, its possible to make the server take whats rendered now and just move it when the window moves, but the event for a window expose is still sent to the application. (and come to think of it, I''m not sure if you can distiguish between "it jsut got moved" and "it really does need to be redrawn")
4) I had something but I forgot it just now.
--
Anyway, has the OP''s question (and the intended topic of this thread) been answered yet?
1) Lag because of the bouncing of the protocol and serial nature of most events. You can''t really get around "X -> client -> X" for things like clicking a button having that cause a new window to pop up. but as the previous poster noted, the WM type stuff IS unecessary, and needs to be redesigned, unfortunately, that mean X12, which nobody really wants to do.
2) Drivers. This is the huge, vast, cover-all-complaints problem with XFree86. "Nobody" notices the above problem since on local machines its blindingly fast. (and "nobody" uses the network stuff, right?) What they do notice is that quake 4 runs with 1 fps. The problem is that card manufacturers don''t like to write open source drivers for their cards.
3) Conventions. Ever wonder why your whole window needs to be redisplayed every time it moves? Yes, its possible to make the server take whats rendered now and just move it when the window moves, but the event for a window expose is still sent to the application. (and come to think of it, I''m not sure if you can distiguish between "it jsut got moved" and "it really does need to be redrawn")
4) I had something but I forgot it just now.
--
Anyway, has the OP''s question (and the intended topic of this thread) been answered yet?
quote: Original post by CoffeeMug
And I''m fairly confident that contacting the developers will get me a typical linuxoid response. "Use the source, Luke."
Would you prefer to not have the source, and reverse engineer it yourself with no help?
At least the source is there and the developers are available to answer (reasonable) questions. What do you want, it handed to you on a plate?
The following statement is true. The previous statement is false.
Shameless promotion:
FreePop: The GPL Populous II clone.
My stuff.Shameless promotion: FreePop: The GPL god-sim.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement