Slashdot Mirror
A New Rendering Model For X
horst writes: "I found this proposal by Keith Packard at mosfet.org. a good article, very interesting." Although it's more than a month old, if you are interested in the state of X, how it got to be that way, and where it's likely to head next, this is essential reading. In fact, you'll practically have to read it to find out why Packard concludes that "[a] new rendering model, designed to solve
specific performance and network transparency issues of these new toolkits, has the promise of significantly increasing the power of the X desktop environment."
You won't get much sympathy in this forum with such views.
Sure, the rendering performance of X can be greatly
improved and those who read the article the might instead
discuss some of the concrete suggestion made there.
X performs well for me on my home P200MMX with a cheap
on-board video card - I always run 16 bit color. It is not as
fast for games as "Direct X" but on the other hand allows
great flexibility and stability with multiple desktops - attempts
at this with Windows are ALWAYS buggy or flawed. I even
get decent performance with Mesa demos and some apps
without a 3d accelerator - of course not for heavy 3d games.
But, with a 3d accelerator you can get very good performance
with such games in LInux or other unixes with otherwise modest
hardware.
I used to be heavy into graphics and was an early user of
Amigas when PC had no graphics to speak of, but I am now
too old?? to get overly excited about ridiculously immature
games like Quake. I'd much rather play something like Angband
these days with NO graphics at all on a text mode terminal.
This is not about performance for the needs of most users,
even professional artists and designers. It's about bragging
rights in playing immature games for preteens on how many
frames per second one gets while splattering blood and guts
in imaginary scenarios.
You can have Direct X for Windows. It's a kludge, a horribly
ugly programming environment and is the one thing besides
the AOL/IE5 combo almost guaranteed to ruin multitasking on
Windows and bring the system down.
Hey, people are working to improve X and bring its built-in
rendering engine up to date. That's good news. Some
important technical issues were discussed in the article.
It is much more likely that such improvements will be made
than that Berlin or something similar will replace X on the
unix desktop. This effort needs support. - and I think it will
get some from the commercial unixes as well as from the
LInux oriented toolkit people (kde and gtk in particular).
Great!
The way I heard it, when work on the Athena toolkit began (c. 1985), Apple was in full look 'n' feel litigation mode. The Mac had just come out and wasn't exactly dancing off the shelves. Now, Apple's lawyers couldn't get you for having buttons and text boxes because the Xerox PARC guys invented those, but they *could* theoretically get you for having scrollbars because the PARC GUI didn't have them-- AFAIK, in the PARC GUI, you scrolled by dragging with the middle button pressed, a method some X apps do support. In other words, scrollbars were invented by Apple to get around the fact that their mouse only had one button! All this meant that, when the Athena scrollbar was designed, the Athena developers tried to make it look and feel as totally unlike the Mac's as they could-- even down to putting it on the opposite side of the widget it was meant to scroll!
This explains why OpenLook had rather odd scrollbars too.
The correct link is Berlin.
'X is too ugly.'
X can be made to look any way you want it too look
It's not X its the toolkit
Every single toolkit is too ugly, therefore X is too ugly.
X is too slow.
Not over a network.
Its not slow, if you have good drivers for the card locally. Especially XFree86 4.0 More than adequate to get work done
DOWNTIME IS GOOD!!! IT GIVES THE SERVERS A REST
X is too old.
Unix is older. 1970.
Linux is older. It was discovered by the military in 1947, in Roswell, New Mexico.
X is bloated.
Name another protocol that works localy and over a network, that takes less ram.
Telnet. 'Nuff said.
X is dumb.
that's a very personal opinion.
But his is right.
X is stupid.
The proper response is no, you're stupid what's so stupid about x
He told you, but you weren't listening. This is an 'all of the above' type response.
X isn't GPLed.
I'm going to assume you mean XFree neither is sendmail or mozilla. there are alot of good non gpled projects. get your head out of your ass.
Only if you get your head out of his ass first. X was GPLed around the time that beta 0.6 came into being. It's just that Stallman never acknowledged that it was GPLed then, because he was working on his own pet project (which he later gave up on), a windowing system for Emacs.
X has a difficult user interface.
X has no user interface. X enables you to build whatever user interface your want on top of it.
No user interface is a bad user interface. 'Nuff said.
Visit HotGrits.Org. News for Trolls. Stuff that Matters.
Hotgrits.Org. Free Speech (As in Trolling).
"Gritz" - Anonymous Coward. (Score: -1, Troll)
"Trollz" - Anonymous Coward. (Score: -1, Troll)
"Natalie Portmanz" - Anonymous Coward. (Score: -1, Troll)
"Linuxz" - CmdrTaco. (Score: 5, Funny)
Only one of those is an actual X problem. The others are application problems, and window mangers problems. They can be solved without changing X.
WWJD? JWRTFM!!!
WWJD? JWRTFM!!!
WWJD? JWRTFM!!!
But, is there a time-table for these changes? Has anyone even started coding this, or is all this really just pre-coding hype?
Alex Bischoff
---
Alex Bischoff
HTML/CSS coder for hire
You have to have negative coordinates sometimes. Otherwise, how are you going to represent windows that are partially off the top or left side of the screen?
The basic problem with making X faster is that it is still essentially a drawing protocol. Most of the proposals to speed up X basically rest under the assumption of making the coupling between clients and display hardware much tighter, which is fine for local display but does nothing for network performance. Berlin takes a more modular approach by separating display components from their application so instead of each application having to specify all drawing operations over some network connection, they only need to communicate high-level results (eg, "button pushed", not "mouse move" "mouse over" "mouse clicked"). The widget components then have abstract interfaces that describe their functions, which can then be implemented by any number of apropriate widgets; applications need only know about the interfaces. This makes taking theming to a really absurd level actually quite easy. You just replace the components that perform those functions. These rendering components then can be tightly or loosely coupled with the actual drawing server as necessary without having to bind the whole application closly to the server, which is where Windows is and where I see X going. Berlin is similiar in spirit to display postscript, but because it's built on CORBA it's a lot more flexible.
Posted by PartA:
>Personally I like the idea of X as a dumb display device. At uni I actually use a X terminal, i.e. a fairly dumb device that connects to a server, they still exist and they still do a decent job. Something which makes the GUI nicer would be great though.
Posted by PartA:
The main reason why you would want a X terminal is likely for the first year students to use. =)
There is very little to break down, they take up almost no room, and basically they get the job done, a PC running as a X terminal on the other hand require far more maintance, more parts = more breakages.
I wonder why none has sold wireless X terminal yet.
For the same reason that someone doesn't write an extension to remove the cruft that's already there. Moral: design first, code later, redesign, code again, rinse, lather, repeat, etc. stop when the design is properly done, properly documented and you KNOW what your software is supposed to do, why it does it, and where its usefulness ends.
John
John_Chalisque
Including a printing API that is part of the display architecture...
John
John_Chalisque
Important consideration needs to be given to the conflicts between pixel accurate rendering and device independent rendering. The latter IMO should be the default, since most often you are concerned with accurately drawing an image on the screen (accurate from the point of view of the person using the system rather than the framebuffer).
John
John_Chalisque
It's funny you should mention scroll bars. I have to use a Windows NT 4.0 box at work, and one of the things that drives me absolutely around the twist (apart from the random lockups) is the behaviour of Windows' scroll bars. They act like ordinary control widgets, and deactivate if you move the mouse too far from them. In other words, if you want to scroll down you have to keep the pointer within a few tens of pixels of the scroll bar in the X direction, or the thumb pops back up to where you started scrolling! Argh! Why can't it just read the Y position?
Personally, I prefer the old Athena scroll bars, as seen in XTerm, with the left/right click to move down/up by different amounts and the middle button to free scroll. I get the impression you're talking about the *look* of the scroll bars, rather than the functionality when you say `how about putting in GTK scrollbars everywhere' (paraphrase) -- this is modifiable by third-party libraries such as Xaw3D -- scroll down the page to see more alternative sets. These changes can be made without recoding applications!
In order to use GTK code changes would be required to all applications with scrollbars. This would be a nightmare, and besides, GTK doesn't have X resources so you can't so easily modify widget behaviour.
It's a shame that X didn't provide an attractive widget set in the first place (or, alternatively, that Motif was, and is, so expensive). Motif, with its rich configuratbility via resources seems cleaner to me in many ways thatn GTK. I presume this will be fixed in later GTK releases, and I hope to see support for X resources at some point...
I've begun to ramble now, so I'll stop, but I'll just round off by saying that vanilla X is almost certainly more configurable than you're giving it credit for.
--
W.A.S.T.E.
W.A.S.T.E.
Which is quite a long physical distance if you run in 1600x1200, which I do...
...by which time you've lost your position in the text you're reading. Why can I not configure this bizarre behaviour?
Just because the functionality is there does not mean that you have to use it.
--
W.A.S.T.E.
W.A.S.T.E.
s/long distance/short distance/
Doh!
--
W.A.S.T.E.
W.A.S.T.E.
This all depends on what you mean when you say "acceptable."
Win98 produces acceptable performance, but my Linux install produces superior results to Win98.
Stating on Slashdot that I like cheese since 1997.
Do you have a more detailed description on how you want this to work? Does it increase the amount of memory needed by the server? Does it increase the amount of network traffic needed? How would it cope with for example a Netscape window that was 500 pixels by 100 thousand, which you wanted to scroll smoothly through?
How about allowing the clients to provide fonts? That would also make it possible for a client to have a backup font that it could use if nothing else was available. Also you might want to consider the possibility of high resolutions like about 300DPI and how they could be supported with a minimum of pain. Display technologies are changing.
And there are a lot of other points you could
bring up, like the ugly security model X has,
or a number of other things. But the point that
I'm trying to make is that while X certainly
has its failures, it also has achieved a number
of really useful things that other living
windowing systems lack. Network display,
flexibility (things like ssh's X redirection magic
and such being possible testify to this),
proper segmentation (so different window managers,
graphical logins, etc are possible), possibility
of X Terminals, etc. Someone replacing X has
pretty high expectations to satisfy.
For every problem, there is at least one solution that is simple, neat, and wrong.
The AWT is too much of a kludge. It started out OK but then there was Swing... the Java equivalent of the client-side rendering that we're trying to avoid here. And plain old AWT widgets just aren't sufficiently sexy or abundant.
Lets not confuse representation with implementation. OpenGL can "represent" all of the features we want, but perhaps doesn't "implement" them all well. I think Berlin made the right choice when they realized they could choose anything which allowed representation of concepts they needed after all the optimized implementations will come later.
Arguments about what in OpenGL can be accelerated applies to both this new standard and the old, and thus are meaningless in the context here. OpenGL supports concept of antialiasing. Only some hardware supports it. This will be true regardless of what protocol the data is sent in.
You can skip the current OpenGL implementation, but skipping the conceptual parts that OpenGL presents seems off. OpenGL is also extendable thus such thinks as a better 2d transparency or font model could be added without need of fresh start. This would make for a more consistant platform overall.
--Karl
X works well for me. I think it does for a lot of people. I don't exactly have the latest and greatest video hardware, but it seems that the X people have done a decent job at keeping up with trends. Not perfect, but what fun is perfection anyway...no complaining to do then.
:) After all, isn't eye candy the only reason most people use X? :) (just kidding)
When he mentioned KDE and GNOME, it made me think that maybe his underlying motive for improving X rendering was to make those funky waves that Enligtenment will put on the bottom of the screen work better.
Only 16 bits for screen positions?
32768 x 32768 ought to be enough for anyone!
If tits were wings it'd be flying around.
I really prefer Athena scroll bars. Depending on where and which button you click you scroll back (or forward) some amount.
You don't have to reposition your pointer when the slider slides past your pointer, just keep clicking the same button and continue. If you only want to scroll a little, click near the middle. Want to scroll a lot? Click near the end.
Want to move instantly to a position in the scroll back? Middle click there. No more having to hit the slider and drag it.
IMO, Mac/Windows scroll bars are crude compared to Athena bars. Just because they look better doesn't mean they're more useful.
I guess this is why X, like the kernel, doesn't try to enforce policy. I like my scrollbars different!
Are these extension going to be added
to the default X version? IE are we
going to see them on other Unix boxes?
-- / The whole history of this invention has been a struggle
senior haus weenie! ;)
How is 3D handled? One thing I always was annoyed by is programs that are made for a different resolution or color depth and just don't look right in a really high res w/ True Color. Is there no way they could make it possible to change the res/depth for individual programs and desktops? BeOS seems to be able to handle this somewhat better. Prehaps X should borrow some ideas from them also. However, my main complaints with X are drag&drop and cut&paste which are both being addressed I think. :)
:)
I tried reading the full set of doc's on X once.. I only understood about half and oooh did my head hurt. That was several thousand pages.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Check out Blackbox if you want to find an incredibly fast, efficient, and well coded window manager.
If we move to a new X (as I think that we should) what are the odds that some programs depending on X will break? I believe that Xi graphics makes a good X server, and I have not heard of it breaking anything, has anyone else?
:).
Still, it would be nice to run other resolutions within a window, (breakage or not!
As per the comment that "X is not GPL'ed" I don't know if a new version should be. Rather I think that a BSD style licence or (rather like apache) it could have both licences. X is not totally closed AFAIK (you have to be on the list to see the code) and I don't know how many graphics card makers would be forthcoming with the code if its fully open.
Then again, everyone (except nVidia Booo!) seems to be going open anyhow...
I think that the licence on a new version is an interesting issue.
Try to hack my 31337 firewall!
The paper notes the increasing dominance of newer toolkits like gtk and Qt, and the fact that they can make migration to X-NextGen easier. On the other hand, they could also make abandonment of X viable. This soul-searching may well reflect an awareness that alternatives loom in the still-distant horizon.
Troll Tech has already announced Qt/Embedded: this allows Qt apps to run without X, using Linux's framebuffer. It offers anti-aliased text and alpha-blending of images, as well as hardware acceleration. Imagine a Gtk/Qt system that can share the framebuffer and bypass X. You could get a lot done with the latest generation of apps, faster, and with less memory.
The apache site defacement was mentioned. Two whole days before your submission date.
Choice of masters is not freedom.
Finally, someone realizes that X needs to be revamped, and actually has a list of what is needed. And we owe it all to KDE and Gnome showing us just where the limits of X are!
:-)
I only wonder that when they're done with it, whether it will be fair to call it X anymore, or if it'll need a zippier name than X12R1
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
I use the remote features of x constantly. I run apps from my home machine at work. I run apps from on of my linux boxes with no monitor on my other box. The remote features of X are the most important features for what I do.
Just ssh to the machine and it forwards x automatically and compresses it. Then run any x program. I do this to lost of machines all the time. It is really useful. It would be very uncommon for me not to have things being remote displayed from several machines on my machine.
Computer modeling for biotech drug manufacturing is HARD!
What does Turing complete mean anyway?
Logic ... merely enables one to be wrong with authority. -- Doctor Who
--Ben
The best way to promote berlin is to port GTK+ and/or qt to it, if you do this you got automagicaly a bunch of application that run on it.
There could be a compatibility layer (reads an X server) that would make all the other work, maybe not as fast, but work.
Done!
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"
[]'s Victor Bogado da Silva Lins
^[:wq
- Assholes that compare X visually to Commodore 64's should be forever forced to use actual Commodore 64's.
And see some of the brilliant demos available for it by groups like Plush, Oxyron, Crest, Smash Design, etc., etc..._______
Scott Jones
Newscast Director / ABC19 WKPT
Commodore 64 Democoder
FC Closer
Yeah yeah, X runs over a network. That's great. I would gladly give up that overhead in a flash if I could get better hardware and font support. In my short 12 years of running X, I have used it over a network exactly 5 times. If I wan't to do something to a remote computer I'll just do it in a shell or through a web browser. That's what I'm using 95% of the time I'm on the machine anyway. Really, now be honest, how many of you people really need to use X over a network? Honest answers please...
Well it looks like people use the networking side of X more than I thought, though I'm not convinced that they are doing anything that can't be done as well through a web browswer or java app, which seem to be easier to implement, more platform independent, and probably less of a headache in the long run. Once dhtml and other advanced web-based specs take foot, the argument for running a low level graphics connection over the network would seem pointless to me in most situations.
I don't think the typical desktop user - the ones that are holding back on linux because of it's gui's and lack of microsoft office - would even care if the network features were missing.
To come up with an idea about how entrenched X is, I propose the following thought experiment: For a hypothetical "Y" Window System, what application programs are on the "must have" list before you'll switch? For me, the list is pretty short:
xterm
emacs
mozilla
Plus, some sort of OpenGL implementation for games.
I'm interested to know what the rest of you think. How many X clients could you leave behind? Which ones would have to be ported?
whuppy enjoys smelling like diesel fuel
Reading through the comments, and seeing lots of negative comments about how X looks, etc.. I just thought I'd add my bit. My X setup looks a hell of a lot better than the Windows interface, BeOS etc, because I run Enlightenment, a rather nifty Window Manager for X.
Go check out the screenshots, and drool. It certainly pushes X to the limits as far as graphical performance is concerned.
"Cast your mind back to 1987"...
like when xfish was new? and X10 was considered cool?
I'm not sure what has been added since then other than non-rectangular windows... and much bloat.
X was desinged to get stupid boxes that could draw lines to do something useful. some boxes were so stupid that they couldn't debounce mouse or keyboard clicks. Now were are stuck with graphics chips that can do 3d texture blits and all they are doing is X-atoms.
A new windows system needs to be designed to deal with issues like:
where are the 3d chips heading?
what do most programs need?
what do the odd ball programs need?
what do the window managers need?
So far all these thigns conflict just enough to keep X alive and kicking.
I really don't think anti-aliased fonts look that much better. I think the problem with fonts is, that the font's that get distributed with the standard distributions are ugly. I have copied true type font's over from a windows computer and gotten much better results. Also I think netscape does a poor job with fonts, which is another reason to think fonts suck. The problem is with netscape as mozilla looks leaps and bounds better with its handling of fonts.
It has been statistically shown that helmets increase the risk of head injury.
There are some interesting points here - I agree that the Motif/Iris/4dWM on Silicon Graphics machines is the best/smoothest/fastest/most intuitive GUI I have ever used, and I would love to see it transferred lock stock and barrel to Linux (which may happen with SG Linux, who knows) but is its smoothness just down to the power of the SGI box?? Does it need serious power to run the threads needed?
I guess todays P3's should be better than the 8 year old SGI Personal Irises I have in my server farm at home, and they can handle hundreds of real time X Clients on my desktop machines.
I think it maybe just takes getting together a good standard (and 4dWM is a good'un) and coding this stuff.
Come on SGI - give us 4dWM for Linux!
Frog51
You are welcome to try.
Sure, but the problem is that many projects get entrenched in designing around design flaws...
Well, as you know the support for OpenGL under Linux is not that good yet (eventhough my GeForce rocks with nVidias drivers). But most people don't have new or very well supported gfxcards.
The claim that OpenGL supports antialiasing is true but only very few cards support it in hardware right now, and falling back to software wouldn't be that fun.
The pixel intensive features of a 2D gui (like fonts) are not that effective in OpenGL (sure you can use textures etc. But OpenGL is primarily for 3D triangular based rendering.
There's is also alot of diversity in the support of blending capabilities among the different 3D cards (it's getting more complete though) but the
most common blendfunc (transparency) is supported by all reasonably new cards.
Doing pixelperfect positioning in OpenGL can be somewhat tricky aswell.
I think the best approach would be to skip OpenGL
and write 2D specific modules for transparency and antialiasing that could be accelerated by the server
I agree, why emulate when you can innovate.
The one thing that impressed me the most about the Aqua/Quartz engine is it dpi independent. I'm am far from a hardware/software developer, but even I can see the evolution in display technology moving to high res displays where 72dpi will be meaningless.
--
_check out yesterday's Slashback about this, links to an explanation of the motives / methods of the hackers as well as the earlier coverage of the exploit in the Apache section. Is this censorship*?_
:-(
No, just an example of my own lack of observation. Sorry.
_*And if a letter to the editor of any newspaper is not accepted for publication, is that censorship?_
Not always, but sometimes. There is definitely such a thing as censorship by omission, depending on the intent/ethics of the editor. However, as I made clear above, I acknowledge that no censorship occurred in this case.
Neopets - the best free game on the Int
Someone needs to tell Apple it's not supposed to use OpenGL for 2D applications. Look here for to see how they are rendering the GUI in Max OS X (aka Aqua) with OpenGL.
Later...
KangarooBox - We make IT simple!
Seriously, I use KDE on my Dual OC 550 Celeron A, but on my P75 laptop, nothing quite beats a well-configured copy of TWM. Has anybody out there actually USED this little wm? It's fast as sin.
> If I was designing a windowing system, the first thing I'd do is make the titlebar only long enough to hold the title.
;-)
:)
BeOS does this.
> Menus would go next to it
I hate the way allmost every other GUI eats screenspace with a long title bar and menu bar. I want the CHOICE of a menu vertical (ala NeXT) or horizontal (typical GUI's) or at the TOP (ala MacOS) or collapsable (has this been done?)
> The problem is although a lot of people will agree with some of these points, not everyone will. Some people want partially transparent windows. Some people want the active window to be the one that the mouse is floating over. Some people like the X style mouse button cut and paste operations. All features that I dislike.
I don't see why these couldn't be enabled / disabled in the interface options in the system panel. There are time I want to change my layout
We need more than 2^15 pixels at the moment ... web browsers, for example, need huge scrollable windows for pages. Things like mozilla do very ugly workarounds to avoid the current X limit.
Either you are very confused or I'm very confused. X does not dictate the call structure or API of all widget sets. The API for various widget sets are different, correct? Sure, most widget sets have "standard" items like scroll bars, buttons, and menus, but they also have those distinctive attributes that make them unique.
If X cast the API of the widget sets in stone when it was first created then there would be no way to "innovate" without coming out with a totally new API, or even worse "patches" to the existing API that are confusing and non-sensical on a regular basis. Hey! That kinda sounds like the Windows API, doesn't it? Every time someone comes out with a new useful widget you have to try to force an existing widget API call into the mold, if the widgets are somewhat similar, or create a totally new API call. Yet, you have to support the old API for legacy applications, so you end up with a jumbled mess.
No, I don't think it would be a good idea for the core X library to dictate a standard API set for widgets, because it would either limit the widgets to the lowest common denominator or create an API hell. I think it's much better for API's to come up with their own API calls and interface for application programs. Since most if not all widgets for X are open source, with the noted exception of motif, a new widget set developer is free to use the existing API calls for the non-unique calls in an existing widget set as the basis for their APIs.
I think you are under the impression that the window manager, which defines the window "dressing" and uses a particular widget set, also defines what widget set the application uses. Like I said, I may be mistaken but I don't think that just because your window manager uses GTK means that all the applications written for KDE with the Qt widget set will magically change appearance to look like GTK applications. At least when I run Kmail on my GNOME desktop it still LOOKS like a KDE application.
I think your beef is with the application developers who happen to use a widget set that you don't like. The only real solution to this is to use market pressure by stop giving the developers of those applications that you don't like your business, and let them know why you are not purchasing their products. Oh, but then most applications for Linux and X are Free, so you really have no ground to stand on and complain! Of course you could send in patches so that the user has a choice of what widget set is used when compiling and installing the applications. May be something like --enable-qt or --enable-gtk? Yes this is sarcastic and a bit of a troll, but IMHO you deserved it. I don't get that people who pay nothing for applications complain about those applications. If you don't like it, don't use it! If you think there are fundamental structural design issues with your platform switch to another like Windows or Mac.
They act like ordinary control widgets, and deactivate if you move the mouse too far from them. In other words, if you want to scroll down you have to keep the pointer within a few tens of pixels of the scroll bar in the X direction, or the thumb pops back up to where you started scrolling! Argh! Why can't it just read the Y position?
That's funny, here, they follow the Y range unless your mouse moves around 200 pixels away from the scroll bar in either direction, in which case they drop, but if you keep the mouse button down and move back around the area of the scrollbar you'll have control bar.
The athena scrollbars SUCK. They just seems like a sad excuse to show off all the mouse buttons.
Lots of people have commented on Berlin, which I was going to do as well. Given that Berlin seems to be making progress now, and that compatiblity libs for X11 apps is of course a future goal, why patch when there's a project to do it all right from the beginning? Can you specifically say why it makes sense to keep revving X instead of adopting something fresh like Berlin?
I was hopeing someone would post about Quartz/Aqua. Although its not radicaly diffrent, just radicaly diffrent from the current implementations. NeXT used display postscript I believe, and most of Mac OS X is based off of NeXT stuff, including Quartz/Aqua. Also I like the idea of a wrapper library, but that might still break some apps. Also what is the network capablitly of the old NeXT display system?
-----
Can I Play With Madness?
X isn't just for monitors - with the X Printing
extension, it also handles printers, and with
a 2400dpi printer, 2^15 pixels is only 13 inches.
>By failing to GPL it, the Xfree86 team has discouraged a major portion of the Gnu/Linux community from using it.
Better tell the Linux distro people from shipping it.
If it was said on slashdot, it MUST be true!
> X was GPLed around the time that beta 0.6 came into being.
Got proof?
If it was said on slashdot, it MUST be true!
The Plan 9 Window System: 8½ has good network support and might be a good start for other ideas.
"What's the point of going abroad, if you're just another tourist..."
In Berlin? I believe the whole system uses OpenGL, for both 2D and 3D. Of course, for 2D it only uses the specific functions that are necessary, as to avoide any overhead.
Unfortunately, it seems to be in its early infancy right now though. Dammit, I want fast graphics in Linux!
Thad
Thad
>Can't the Amiga do this using RTG?
No, RTG is more like VNC than X. It allows you to
open an Amiga screen into a PC window. At least thats what I've read about it.
Tim Malone
> 'X is too ugly.'
> X can be made to look any way you want it too look
From a usability standpoint, that's an insurmountable problem. That reason alone should be reason enough to get rid of X. Even if you could present a user with a consistent interface, if they wanted to download programs on their own, their interface would shortly become inconsistent, because most X programs looks different. An example is ETerm. I download the new version the other day. But what happened to the menu? Then I discovered to access the menu you have to do a Ctrl-Right-Click. Perhaps when people start figuring that out, they may change it to something more obscure. It's possible to code bad interfaces in any enviroment, but good environments such as Mac/Windows/NeXT make it easy to develop interfaces that are the easiset to use.
> X is too old.
> Unix is older. 1970.
Considering how far graphics has come in the last decade, I think this is a valid complaint.
> X has no user interface. X enables you to build whatever user interface your want on top of it.
To repeat, this is why X has got to go! No matter how much you improve it, it continue to be a complete mess, interface-wise.
It took Be forever to get their system usable, and it's still not as stable as X. I think the incredible amount of time that it has taken Mozilla to come together demonstrates this as well.
The thing with working code is that god only knows which subtleties are critical and which are just cruft. Changing them individually allows you to learn and improve. Throw out the whole thing and you've got to remake every mistake made the first time around.
doesn't XFree 4.0's DRI qualify as a new rendering model?
the whole book is thoroughly recommended for even the hardest to die unix die hard
.oO0Oo.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I don't agree. Graphics adapters push many million polygons per second when using OpenGL nowadays. Drawing window borders (or button or scrollbar) is no job for recent graphics adapter. With OpenGL you get texturing, anti-aliasing, alpha-blending and z-buffering (I can imagine many nice effects with z-buffering in window manager) practically for free (because those are implemented in hardware). Also GLX makes pretty good use of network bandwidth in my experience.
_________________________
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
I tried it, but nothing showed up on my Netscape 4.72 browser.
Will I retire or break 10K?
Umm... Aqua is not being done with OpenGL. Apple rolled their own new display API (Quartz) which is based off Display PDF (NeXT always used display Postscript, but that had too many patent issues for apple's taste). OpenGL is also there, but it's not what's behind Aqua.
Then again, AmigaOS graphics system was tied heavily to the hardware until OS version 2.x, and even now it's not IMO as good with graphics cards as Windows or X.
Everyone who makes generalizations should be shot.
I have used X for about 5 years and it's not that uncommon for me to use some application that is installed at the university machines but not at my own Linux box (or even isn't available for Linux) over network. I can't give exact figures of use, but about once or twice per month should be quite close. It's not very important, but I'd miss the feature if it would disappear...
Everyone who makes generalizations should be shot.
You want source access then join the development team.
Only the State obtains its revenue by coercion. - Murray Rothbard
Maybe you guys don't have your MTRR set properly or something. My X runs like lightning on this 3dfx card. Without MTRR support it does suck so maybe that is your problem. Look into it!
Well, on the plus side, my C64 takes a lot less time to start up than X. And its much more memory efficient. And Spy Hunter is more fun than any of the games I've seen for X. And my TV gave hardware anti-aliased fonts.
Berlin probably won't become popular because many folks will say, "Gee, why code for it? There aren't any apps yet"
This could be solved quickly by porting gdk/gtk to it. Suddenly we have Gimp, a web browser, and - the most important addition ever to the modern GUI - Minesweeper.
As for the point about gtk, Windowing systems are different from toolits. You can easily use several toolkits, but using several GUI's is a lot harder.
X on a network is truly impressive (I had great fun playing Doom on two different machines using each other's monitors)
The thing is that not many people use their machines on a network. X really needs some optimisations to improve local display support.
Name another protocol that works localy and over a network, that takes less ram.
Can't the Amiga do this using RTG? Probably less efficiently in terms of bandwidth though.
How about support for multiple desktops at different resolutions and some decent stuff for full screen games and video. And I'd quite like to have Windows style subwindows.
The problem is when moving objects around the screen it's nice to have the same pixels drawn, but when using floating point, the precision depends on the magnitude of the value. This means you get different jaggies on the edges depending on where you draw something on the screen. Not pretty.
I conclude that 32-bit fixed point numbers are a better fit, and that providing 24 bits of integer part and 8 fractional gives a good tradeoff between rendering accuracy and an extended coordinate space.
Perhaps you meant that X should have had a standard toolkit, and forced everyone to use it.
No, I mean that X and a standard tookit should be the same thing.
Having one without the other is useless.
And if X and the toolkit WERE integrated, then the wire traffic could be done at a much higher level for common user interface tasks.
Think: move scrollbar thumb to possition 8 on window foo
Instead of: several K of bitmaps, or many many colored linedraw operations
The designers of X wisely adopted a philosophy of "presentation, not policy"
Wise? I don't think so. This was their biggest mistake. If X had handled Windowing, then you would have had a uniform set of conventions for windowing, AND you could have extended or improved X Windowing.
If everyone hated the way scrollbars worked in X8, then in X9 they could change it and it would just work!! This is exactly what happened when M$ Went from Win3x to Win9x. Every application that used scrollbars in the 'usual' way. Got the new scrollbar look and feel for free.
"Presentation not policy" is PRECISELY why X is such a cluster-fsck. It's a completely inadequate design for use as a GUI.
But moving from X10 to X11 broke pretty much everything. Albeit, there were *ALOT* fewer apps back then. (Hmmm... There was xterm and... ???) :-)
But, I take your point, breaking everything currently available for X, including all the window managers, other apps and toolkits which run on top of it would require some serious justification. Then again, where would be the justification for an entirely new windowing system? A new improved X that breaks everything, starts out on a level playing field with something new like Berlin.
F U NE X N M? Son: "Dad... How do you spell 'hourly'?" Dad: "0 * * * *"
Anyone remember the RISCOS font manager? Drawfiles? I seem to remember using 32-bit fixed-point co-ordinates and anti-aliased fonts on an A5000 a *good* long while ago.
"Knowledge is the continuation of ignorance by other means"
Why the fuck is this thread displaying all messed up? Word wrap is broke or something. Some posts are fine. Some are extending 20 lines as 1 line. Gotta scroll right about a half mile to read them. Every other article is fine. this is the only one that is fsck'ed. Is this just me?
Shame there aren't any HCI researchers working on this stuff. User interface is what lets down most wm's, especially the flashier ones.
-- The point is, X works, but you could have something so much better if "the community" just tried. But it won't. --
Now where have I heard that before... could it have been... s/X/windows/; ... oh yes, that's it.
note to people who want to flame me: I'm a windows user and proud of it. I usually get uptime of up to two weeks (at least unless my ip leaks to some 'l33t linux-people). The very reason I'm using windows and not linux is that windows has what I need, it's stable enough for me. I suppose people use what works and does the stuff for them and what they have used to use, instead of seeking for "something better".
-- Matti Nikki
Sounds like this will open up a new world for Window Managers. I wonder what kind of new things could be done with changes on a lower level (read, X)
I have been learning Linux for the past 1.5 years and I am verry pleased with it. I like the way it is designed and I especially like its multitasking and SMP support. I'll try out BSD later, but Linux will always be apart of me. I have ditched Microsoft. I payed $200 for MASM 6.1 and I thought I didn't get much. My first Linux purchase is a Linuxmall.com RedHat 5.2 CDROM and powertools CDROM which I payed $7 on eBay. I was stoked whith all the information that I received. I am verry greatful for all that the Linux forefathers have started and ma proud to say that I will never graduate from the Linux operating system because its greatness goes on. The open-source philosophy is helpfull than closed-source. I found it much more challenging to program under MS Windows. Especially when nobody will show source code, or at least, source code that has some structure and is self explanatory. I went to hotgrits.org and I don't like what you are doing. You can have that website for yourself and all of your perverse frieds. Slashdot.org is where the information is at. It is only a matter of time before some causes DenialOfService on your system or, atleast, cracks it down to a dump of /dev/hda. Why don't you take some time off the internet and grow-up. Keep in mind that the previous sentance is a command, not a question. Add infinitum. Slashdot.org lives on!
without prejudice
It was posted awhile ago in the apache section with detailed commentary about how the break in was accomplised. Read the other sections.
If you liked this thought maybe you would find my blog nice too:
Other than the PowerPoint graphic, do you know what specifically in the GUI they are using OpenGL for?
My reading of that graphic is that OpenGL and QuickTime are available as parts of the display API, not that GUI elements would necessarily be rendered with QT movies or OGL elements.
When I hear the word 'innovation', I reach for my pistol.
The behavior can be specified with SqueezeTitle and DontSqueezeTitle in the twm startup file. It can even be done on a per window basis.
I should have made this more clear... I'm not suggesting using all of Sun's baggage (and all the licensing problems thereof), just using the core Java language with a logical interface to the [possibly expanded] core X11 primitives.
--
Sometimes it's best to just let stupid people be stupid.
actually, I prefer the virtual desktop. Since when does anybody go to a lower color depth to have a smaller desktop? usually just to zoom in, or play video of games.
Whats with that horrible flicker that first happens while going into X? That alone makes it look ancient. This has to happen if Linux or any other*NIX is going to make it in the desktop market. That besides installing new software would scare most newbies away from it. This looks like a step in the right direction
Excellent, I've always wanted PostScript capabilities within X. ;-) Floating point coordinates and 2x2 matrices for rotation/scaling too ? Have you looked at QuickDraw GX as technology guide for building the X infrastructure to deal with documents ?
Sigh. You've described NeWS, only pull out "java" and put in postscript. (People don't seem to realize that postscript is turing complete).
And no, java isn't even remotely perfect. There is way too much extra shit in java. Postscript is a much better fit to this problem.
Postscript is the second worst programming language I have ever encountered after Sendmail (which has Turing complete rewrite rules). All the slowness and unpredictability of a very high level language and all the incomprehensibility of assembly. Even Adobe seem to be keen to kill it in favour of PDF.
And Postscript has *way* too much extra shit in it. Java doesn't have "save/restore", for example, which was always madness and looks madder than ever when looking at interactive stuff.
Java is certainly the right fit for this problem. I agree that this would be very desirable. Not Swing or whatever, just the core Java language combined with a rendering model designed for this problem.
--
Xenu loves you!
Turing completeness is meaningless in the case of a display architecture. For example try writing a windowing interface in TeX (which, alas, is also Turing complete).
John
John_Chalisque
>Other graphics system for linux such as berlin aren't going to become the future due to their lack of software.
:^)
:^)
Erm...I remember someone saying once that the toolkit GTK would NEVER become popular because:
1) there were already a number of toolkits "out there"
2) there was only one app that used it (GIMP)
And now look.
The moral: Berlin probably won't become popular because many folks will say, "Gee, why code for it? There aren't any apps yet." It's kinda like Catch-22: You can leave the army if you can prove you're crazy; however, if you can prove it, you must be sane.
Stating on Slashdot that I like cheese since 1997.
Is that X does so many things acceptably. X isn't
perfect, but there are so many things that it does
right over its surviving competitors (e.g. the
Windows GUI) that improving on it will be very
difficult. There are so many important features
of X that people who try to write a replacement
would be tempted to take out to make the ship
date sooner that it seems unlikely to me that
a replacement will come along soon.
For every problem, there is at least one solution that is simple, neat, and wrong.
The proposals sound very good. One thing that I feel should probably be incorporated in this type of project - to improve what was left out of X rendering - is the addition of a parallel API that allows each rendering function to be applied directly to some array like structure like an Ximage on the client side. There are lots and lots of applications that need to give the user choice between screen display and/or output to something like a PNG image, and this type of API would make doing that more straightforward.
I have read your proposal for the extensions to X and have a few
comments on it. I have worked with X a great deal myself, writing 2-D
graphics manipulation programs at Digital Domain, large amounts of GUI
code, and a toolkit (www.fltk.org). I would be willing to help out
with coding or ideas or anything, as I see the replacement of the bad
parts of X as being vital to the future of it.
Certainly we NEED to replace the X rendering engine and this goes a
long way. I also don't think any replacement will be accepted unless
it is possible to emulate the old system atop the new one, and to
emulate the new one (slowly) atop the old one, so that a gradual
transition is possible. Adding things to the X protocol looks like
the only way to do this.
I don't like the fact that you seem to be concerned with moving the
minimal amount of drawing code to the server. I think this is wrong:
I want the server to do absolutely as much as possible. We have no
idea what may be hardware-accelerated in the future. I am also tired
of trying to use a bunch of shared library which don't understand each
other and don't cooperate to draw things.
COLOR VALUES:
I disagree with your desire to keep the pixel values and the raster
ops visible. These are not needed for any modern graphics system,
based on the stencil+fill model. I am also afraid that if they are
not gotten rid of completely it will greately decrease performance.
On all hardware I would like to see colors directly specified (at
least with 32 bit rgba numbers, perhaps other ways). The driver
figures out how to represent these on the hardware. I do not believe
the translation is that expensive: it is certainly cheaper for the
server to do this translation because it has ONE target format, rather
than having the application do it to a arbitrary target specified by
the server.
8-bit hardware colormaps can be filled and the closest available color
used when the map is full. This is the solution used by all toolkits
today and I see no problem with moving this to the server. Filling
colormaps is one of the big round-trip time wasters with X. If we
added one more call indicating "I don't want this color anymore" then
colormap cells can be reused without closing the connection.
For emulating old xlib programs I would have the interface claim that
only a TrueColor visual is available with 8 bits of r,g,b. This will
allow the deletion of all the old colormap stuff from the X server and
allow great freedom in the new implementation. Programs that cannot
use TrueColor are not going to be supported (this is already true for
XFree86 in 16/32 bit mode so I don't see this as being a problem).
The only useful "raster op" is "XOR" and that is only useful for
drawing "overlays". Exposing this prevents the server from taking
advantage of real overlay hardware. I would prefer to have "draw in
overlay" and "erase from overlay" added to the gc. On simple hardware
these both do XOR. On more advanced hardware the overlay is used, and
maybe the current color.
ALPHA COMPOSITING:
It may be important to support "premultiplied" alpha compositing,
which is A+(1-alpha)*B. This form of image is often generated by 3-D
rendering programs. The non-premultiplied version is actually better
but the premultiplied form is so common that it must be supported.
I would also like to see non-premultiplied alpha "paint", ie you can
set the current foreground color to have alpha. This does not need
hardware acceleration but should be in the server.
Far better antialiasing can be achieved by taking into account the
actual brightness of pixels on the screen (the screen gamma). The
proper way to add screen colors is (A**(1/g)*alpha+B**(1/g)*(1-alpha))**g,
where g is the screen gamma (approximately 2). I think this can be
done with a lookup table?
COORDINATE SYSTEM:
I think you *should* use IEEE 32-bit numbers and put the
"transformation" into the server. You must support Inf and not crash
when NaN are passed in.
Using floating point is the only way I see to avoid having two
clipping bottlenecks (one in the program to clip to the legal
coordinate system and another in the server). Clipping is NOT as
cheap as you said, as it involves calculating a new path by
intersecting the lines with the edges of the clip area.
Having the transformation in the server is necessary for supporting
font rasterizers and to take advantage of hardware acceleration for
transforming images.
The translation inaccuracy problems you mentioned are eliminated by
having a current transformation, if you seperate the current
transformation into an integer translate and a fp matrix. The program
can then translate so that 0,0 is on the screen and draw with very
high accuracy.
It is not necessary to have a transformation stack, just setting the
current transformation directly would be sufficient. However I would
not complain if there was a stack.
PATHS:
I do think paths should be in the server, because otherwise people
will write wrapper libraries that will be slower than doing it in the
server. Like PostScript, paths are built using the current
transformation, they do not move when you change transformation. This
allows them to be converted immediately into trapazoids.
Characters may be drawn into the path. Since these are antialiased
bitmaps from the font renderer this means the path must support
antialiased bitmaps. Also current X supports the ability to add 1-bit
masks to the clip and it seems likely you will have to support this
for back compatability. Therefore it seems likely that the path must
be an arbitrary gray-shade image (internally stored much more
efficiently as a combination of images and trapazoids). This is a
pain but I see no way around it.
Unlike PostScript you can probably require the program to say what it
is going to do with the path before it builds it. "Stroke" for
instance would be totally different and could ignore bitmaps (or draw
a box around them).
"Fill" would fill the path. It may help to insert some OpenGL into
here and allow the color to change as the path is built and it then
did Gourand shading of the path.
"Clip" would use the path to set the clipping area, intersecting it
with the current clip.
It would be real nice if a window could be created with the current
path, to replace the "shape extension".
TEXT:
I do not want the Windoze-style 12-parameter call to sepecify a font,
and I am afraid this is what you are suggesting. I recommend a call
much like this: setfont(gc, const char* name, int attributes, float size).
The "name" should be something that we are willing to show a user,
like "Helvetica". The attributes are bitflags for bold, italic, etc,
but in all cases the same attributes may be achieved by adding "
Bold", " Italic", etc to the name and leaving the attribute zero. The
size is a convienence, as the current transformation should be used to
figure out the letter forms, the size temporarily scales the
tranformation by that factor, sets the font, and scales it back.
The PostScript model where the size is the true "point size" MUST be
used. This means the size is the minimum line spacing, not the ascent
size that has been popularized by broken Windoze and Qt. This is
necessary to typeopgraphy and for supporting non-Latin fonts.
Another pet peeve: can I PLEAD with you to support UTF-8 (and ONLY
UTF-8) encoding! This is a standard to translate 8-bit bytes into
Unicode indicies. I don't care if you draw a box for every Unicode
character not in the font, just support the $#$%@ encoding! I believe
there is NO need to support plain 8-bit or "wide" characters, but I
know others disagree. Illegal UTF-8 sequences (including characters
encoded longer than needed) should be represented by using the bytes
individually. Change Unicode by replacing 0x80-0xA0 with the
MicroSoft character set, because we must face the fact that they have
taken control of this standard.
Measuring text for layout is a problem. Any kind of character
metricies system prevents the server from doing intelligent kerning or
overprinting, it also requires the application to understand UTF-8,
which eliminates the whole point of UTF-8! Any other solution would
look like HTML, greately limit the amount of formatting control the
program has and being very complex. I think we have to give up on
eliminating the round trip and recommend instead that the gc have a
"current string". The program sets the string to an array of bytes
and then can request the metricies of how that string would be
formatted (ie the bounding box, etc). The program can then tell the
server to draw the string, or it can change the string by either
replacing it or truncating it to a substring. This at least
eliminates the need to send the string twice and lets the server cache
info it got when it measured the string.
IMAGES:
Again, I STRONGLY disagree with the conventional wisdom that the only
fast way to do images is to have the program know the details of the
hardware. Though true in theory, the pratical solution is to have an
ENORMOUS library that can translate all possible pixel formats the
program has to all possible ones that any server has. Doing this in
the server is MUCH simpler, since it only has one target format,
reducing the complexity from N^2 to N.
I would greatly limit the number of source formats to ones that are
needed by modern programs. This means ONLY these:
"native" : a single format the server likes, much like X is now.
1-bit black & white
8-bit gray level
8,8,8 full color RGB
8,8,8 full color BGR
8,8,8,8 full color with alpha non-premultiplied RGBA
8,8,8,8 full color with alpha non-premultiplied ABGR
8,8,8,8 full color with alpha premultiplied RGBA
8,8,8,8 full color with alpha premultiplied ABGR
Just so people won't scream about my color limitations, also support
8*2^n bits per color, though this can be done by skipping the
low-order bytes for now.
The recommended call is this (or a seperate call for each format):
draw_image(int format, const char* data, x,y,w,h,delta,linedelta)
x,y define a position in the current coordinate system for the
upper-left corner. w,h define the width & height of pixels to draw.
Delta is the data increment between pixels (this allows other pixel
data to be skipped, or the red channel to be drawn monochrome).
Linedelta is the data increment between lines, this allows arbitrary
subrectangles of an image to be drawn. Both delta and linedelta may
be negative to flip or rotate the image.
It may also be useful to send raw jpeg or png data to the server and
let it be decoded there. This has obvious benefits for a network, and
also eliminates another need for many programs to link in another
library.
OTHER FIXES TO X:
Make a new type of "gc" that includes the damn window! It is
ridiculous that we have to send both the window and gc to all the
calls. Deletion of the window id would also shorten the protocol (it
is vital that the window be changable with a setWindow call, the lack
of this makes the Win32 gc's nearly useless).
Add a call that can define a huge array of atoms with a single
protocol request and a single round trip. This along with the
elimination of colormaps would get rid of most of the startup delay of
X programs.
Fix the X protocol so there is a symbol sent when an application is
waiting for events (actually it would be sent by XFlush if the buffer
is not empty). This would allow servers to synchronize updates with
vertical retrace, do double buffering, and consolidate mouse events.
It would also allow synchonrization with the X window managers: one
real annoyance with X is that you cannot map a window and immediately
draw into it, this looks horrible to programmers used to Windoze and
almost certainly needs to be fixed before they will be willing to work
on X.
--Karl
Yes, NEXTSTEP and OPENSTEP use Display PostScript. So does Mac OS X Server.
NEXTSTEP and OPENSTEP (hereafter NEXTSTEP) work much like X does: you can display applications running remotely on your screen. But both ends have to be running NEXTSTEP, and the applications have to be native NEXTSTEP applications. That is, you can't display a NEXTSTEP application on your Linux box running X, nor can you display an X client application on your NEXTSTEP machine (unless you're running an X server on that machine, of course).
Quartz no longer uses Display PostScript, as Adobe isn't interested in licensing it (at least not for a low enough price). Quartz is more like ``Display PDF'', and it incorporates much of the font and text support from the orphaned QuickDraw GX.
Also, Quartz is the imaging model; Aqua is the interface. Aqua needs Quartz, but Quartz doesn't need Aqua.
In other words, if you want to scroll down you have to keep the pointer within a few tens of pixels of the scroll bar in the X direction, or the thumb pops back up to where you started scrolling!
I hate that too, and I've sometimes wondered whether it was a side effect of the Apple UI lawsuit... Microsoft would be seeking to distinguish its UI from Apple's to thrawt the copyright claim. Surely not even Microsoft's UI designers would intentionally design in such an annoying and distracting feature.
BTW, Apple's UI is also sensitive to the pointer's X location, but if the pointer wanders outside its "slop" zone, the scroll thumb simply freezes in place -- much friendlier that jumping back to the top of the scrollbar.
But simply tracking the Y position would seem to be both the simplest and most obvious thing to do.
--Jim
There is a successor to NeWS, and it's called "Java": same PostScript imaging model, same stack oriented architecture, developed by the same person.
Java is hardly a successor to NeWS. Yes, they have some similarities, and both represent attempts to move more application logic into the client machine. However, Java is a programming language, not a windowing system. Java depends on X11, NeWS was a competitor to X11. Calling Java a successor to NeWS is a fairly imaginative stretch.
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
It's easy to look back on NeWS and only remember the good things about it. I remember the NeWS server crashing all the time because of postscript bugs when some app tried to do tricky things with popup menus.
That's true, but don't you think those bugs would have been fixed years ago if NeWS won in the marketplace instead of X11? (Early versions of X11 weren't bug-free either...)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
One thing I'm wondering about is whether this X11 extension could not be based very directly on a 2D OpenGL subset--it's an API that a lot of people have experience with, that is well documented, and that's already part of many X servers. It's just a suggestion, and it might end up being somewhat of a compromise, but it might also help with the widespread acceptance of such an extension, because it would be really easy for many toolkits and applications to start supporting much of it immediately.
I used NeWS for a while and found it has some serious problems when it came to reliability, isolation of different applications from one another, etc. Java addresses these issues.
The only thing that is really missing is network transparent C++ bindings to the Java toolkit. With SOAP, XML-RPC, or CORBA, that wouldn't be too hard.
I don't think there is a conflict: pixel accurate rendering and "photographic" rendering (color models, antialiasing, etc.) are two different imaging models. X11 with the proposed extensions will support both, and that's good.
I think that's throwing out the baby with the bathwater. A lot of the stuff that makes X11 complex (pixel accurate rendering, pixel value manipulation, network transparency, properties, security, etc.) is intrinsically complex. Most other systems don't even bother offering a similarly complete package. BeOS, MS Windows, MacOS, and NeXT Step all address some aspects of it, but they also cut a lot of corners so that they can be targetted well to their market niche. That makes them a lot simpler and easier to deal with, but it also means they are not as general. I like X11 because it covers so much ground.
As I understand the proposal, it would not replace the old imaging model. In fact, I think it shouldn't. Pixel accurate rendering and bitwise blit operations are still important today. The requirement for the new, additional imaging model has come about because of new uses, and the logical way is to address it with an X11 protocol extension.
It's a shame that X didn't provide an attractive widget set in the first place (or, alternatively, that Motif was, and is, so expensive). Motif, with its rich configuratbility via resources seems cleaner to me in many ways thatn GTK. I presume this will be fixed in later GTK releases, and I hope to see support for X resources at some point...
I've begun to ramble now, so I'll stop, but I'll just round off by saying that vanilla X is almost certainly more configurable than you're giving it credit for.
It probably is, but still:
I'm not saying that X, by itself, should have had a widget set. X's modularity is one of it's few truly good points. But what they should have thought to do is provide some kind of place to call the widgets-- i.e. a standard set of stub libraries or somesuch, where the application simply requests a widget of a certain abstract type, and whichever widget system is installed on the computer at the time handles the request. (i guess today we'd do that with some kind of XML, dunno how they'd have done it then..) I believe doing a similar thing to the open/save dialog boxes would seriously improve the *n?x experience.
The scroll bars were not meant as an example of something fundamentally wrong with X, just as an example of something that X users put up with for no apparent reason. Because even if it is somewhat configurable, you have to admit that the widgets in your average linux install are something of a mess, and certainly no better than mediocre. And yes, scrollbar appearance is a nitpick, but it's a pretty damn huge nitpick.
"configurability" isn't the issue-- just that the X people should have thought ahead enough to realize, y'know, at some point people are going to be designing widget systems. If they had thought to provide a nice little place for widgets to plug in we wouldn't have the problem now of having to totally recode everything in order to switch between Motif/Athena/GTK/Qt. Even if it wasn't their responsibility to have solved the problem ahead of time, the problem should have occurred to them.
I, too, am now rambling, so i shall stop.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Actually, the Amiga was clever about scrolling - the scanlines didn't have to be contiguous in memory, every line (in fact, every group of 8 or 16 horizontal pixels) could come from a different memory location. That's because it had a 3-instruction (MOVE, WAIT, SKIP) beam-synchronised co-processor called the Copper.
Thus, to implement scrolling, rather than copying memory, you just said "change the bitplane pointers to display one line further down at this display coordinate (in fact AGA amigas also had 1/4 pixel positioning for sub-pixel super smooth scrolling.)
It's a quite different programming paradigm, and it's why the Amiga versions of all those old 2D games like Sensible soccer, lemmings, etc, all scroll much better on a 7MHz A500 than a 200Mhz Pentium, and it's why the Amiga, rebadged as the NewTek Video Toaster was king of the mid-range video and animation world for years.
At one stage , a company called Phase 5 produced a Vaporware plan to produce an Amiga successor, in which every pixel could come from an arbitrary memory location.
As an aside, the amiga also had another custom subsystem, the blitter (Block Image Transfer) which shovelled rectangular areas around memory, somewhat like the 2D-acceleration that PC cards came up with some time later, and it did hw-accelerated line drawing and flood fill operations too.
The intersting thing was that the Copper, Blitter and CPU could all trigger CPU interrupts, the Copper could trigger the Blitter, the Blitter and CPU could operate on memory that stored CPU and Copper programs (the Amiga had a unified memory architecture). Thus, you could make really insane self-modifying programs, once you stepped outside the bounds of the operating system - which is why Amiga Demo coders came up with such wierd effects (well, that and the acid.)
Choice of masters is not freedom.
You like CDE on Sun? The $4000 UltraSparcs (266 mHz, I think) we have here on campus display graphics MUCH slower than my PII-350 with Linux, which was $1000 in the same era. CDE frequently locks up on its fancy splash screen (this is Solaris 8, too), so many of us just use failsafe logins now. The Display PostScript seems like such overkill for the graphics that these things display: mostly just windows/web pages or OpenGL graphics (which aren't exactly postscript material). I just don't see the benefit to relying on it (I've written plenty of postscript and I know how odd, but interesting it is).
--JRZ
I scanned the replies to this article, and although there was lots of heat and a little light about various display models and what should go into the "next X" from a graphics point of view (personally, I like a Java-based approach), I saw no one bring up the fact that any "Xng" that's going to serve us well needs to be able to be able to connect audio over the network as well as graphics and standard device inputs.
This is really not an option in today's multimedia world. If this isn't built into Xng, then machines that rely on X will fall further and further behind the competition. Note that this would require at a minimum, CD-quality audio from X client to X server, and ISDN-quality from X server to X client.
Real touchscreen support should also be in there - that means not just something that pretends to be a mouse, but something that provides the fundamentals required by gestural interfaces, perhaps with a set of gestural recognition primitives. (Which raises the question of whether or not X should include written character recognition as well - given Linux expected penetration into the embedded space, this can be done once well, or many times probably not so well.
Remember, good programmers write good code, great programmers steal (leverage somebody else's) good code. Xng should have good stuff to steal.
"The future's good and the present is nothing to sneeze at." - Roblimo's last
Wouldn't this rather require a separate X server for printing? I don't see why the computer I'm typing at should do any processing of a print job. It seems to me that that should be between the computer I'm running on (the X client) and the computer the printer is on.
It seems to me that this is the big advantage of the client server architecture of X. Why should every user have to upgrade the X server on their box just to use the printer?
Personally I like the idea of X as a dumb display device. Although antialiasing and alpha would be nice.
Isn't this what Berlin trying to do??
It's 10 PM. Do you know if you're un-American?
Yes, I think I'll run home now and code an alternative to a 100,000+ line windowing system. Good idea!
These are only slightly exaggerated. The general trouble with most things X or Linux related is that any fool can see how messed up they are, but much effort is put into defending them. We put down Windows, yes, but we defend our mistakes forever. Remember, UNIX was heavily criticized and out of favor in the the late 1980s, even to the point where it looked like it be on the way out. And those same criticisms are still applicable today.
Because, generally, 2d OpenGL operations are *really* slow compard to equivalent ones on a direct framebuffer, or even through the framebuffer. OpenGL drivers/implementations are designed and optimized for 3d applications --- they simply include 2d functions for completeness. No one in his or her right mind uses glReadPixels when performance is required --- instead, they use textured quads rendered in orthagonal mode, which is a nasty trick.
I'd like to add one additional request in the name of bandwidth reduction. Display lists. One of the more interesting things about NeWS (Sun's post-SunView windowing system based on PostScript) was its ability to be programmed. You could create a routine that could render a whole button with bevels and shading and whatnot as a single function call whereas in X it will typically take six or more protocol requests to get the same job done.
While full programmability ala NeWS is rife with potential problems, given just the ability to record a sequence of parameterized protocol requests and request playback would drastically reduce the bandwidth requirements and boost the performance of a lot of applications while having very little impact on memory use. I believe display lists were considered and discarded originally due to the requirement that X11 run in a terminal with very little memory (too little to hold much in the way of display lists). I've never appreciated that since the client-side fallback technique was always a viable option, but given the opportunity to extend the protocol I think this would be something to consider.
jim frost
jim frost
jimf@frostbytes.com
I am so glad to hear that people are considering what to add to X to make it more competitive with that "other" window system. Most of the items listed are great, but I'd like to add one more item: the ability to change the color depth of the server dynamically. Granted, this may become unneeded as video cards get enough memory to run 32 bit color all the time, but until then I'd like to be able to run 1600x1200, but drop res and pick up colors if needed.
www.eFax.com are spammers
Not to bash X, but I think it's time to seriously think about a better system. As in many projects, there's a lot of compromise involved in X. While it does a fairly good job, the fact is that it's rather crufty. Compare the relative sizes of the X codebase to the Kernel source and you'll see what I mean. Of course, in some ways, a graphic architecture is a more daunting piece of work than a kernel, but it still seems like X is rapidly showing its age.
If we want to have all the spiffy extras like anti-aliasing and alpha-blended transparency, X is going to have to be adapted. In the long run, it may be better and more efficient to build a new architecture from the ground up to meet the need of things like advanced OpenGL and user interfaces. One of the things I admire about the BeOS team (OK, the *only* thing I really admire about BeOS) is their dedication to ending cruft. Eliminating the crufty X Windowing System would greatly aid the stability of Linux and make it more competitive against that other little OS from that little concern in the Pacific Northwest.
Now, having said that, I realize it's easier said than done. However, we have a clear roadmap of what this new system needs to do. This could be another way of showing how Open Source can meet technical challenges better than closed development methods. Yes, it's a daunting project, but one that could have some great benefits to the OSS community at large.
ahhh yes, those where the days. When 256 was "real color!"
Frankly I think that most of Xs problems today is that it knows it's own history to well.
___
Of course the look and feel of the newer systems is still much nicer, and they're much more intuitive about various operations, so why bother?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
> Font support is nonexistent.
Well it's not nonexistant, but it is quite a mess (at least for scaleable fonts). Point taken, but that is exactly what this article is talking about work on.
> Cut and paste is a mess
How so? I personally like hilite-middle-click copying. d&d is an incompatible mess that needs some help from the Xlib level so that different toolkits could get along, but the X11 cut-buffers work quite well I think.
> On startup of FVWM, kde, whatever...
You need to talk to fvwm/kde/whatever about this feature. X has nothing to say about virtual desktops, which are a window-manager creationand as such are managed by the windowmanager.
> With the current X release, no way exists to specify the location of pop-up windows
You mean the x,y,height, width, and Zorder (force to be on top) windowmanager hints? If your windowmanager doesn't respect them, I think that's it's problem. certainly X provides a way to tell the WM that this window should be here, this size, and always on top (thus avoiding the problem of being 'hidden under other windows'. In any case, a modal window should block only the one app it relates to, so killing the offender should be quite simple.
> A global way of assigning keystrokes to all apps under X.
There is one and only one X keymap (handled by Xkbd extension and tweaked by xmodmap). There are lots of ill-behaved apps that can't agree on what should be in it, but this is an issue exposed by the cross-platform heritage of these apps, not an inherent X11 problem. GTK and QT have gone a long way toward fixing this, it's just a matter of getting legacy apps tuned up.
It sounds to me like you don't like your windowmanager, and are blaming X for it's problems (an easy enough confusion - most other platforms don't have the distinction between graphics API and window-policy that X does).
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
Every single toolkit is too ugly, therefore X is too ugly.
I'll give you that for Motif, but GTK and many WMs can be themed. If you don't like how your widgets look, go to themes.org and pick up a theme or two.
Will I retire or break 10K?
If we move to a new X (as I think that we should) what are the odds that some programs depending on X will break?
There will probably be a new X11 server running as an X12 client, that translates X11 calls into X12 calls.
Will I retire or break 10K?
One obvious coordinate representation is IEEE 32-bit floating point numbers. The 24 bit mantissa specified by IEEE would provide at least 8 bits of sub-pixel position within the 16-bit X coordinate space, and would be easy for applications to manage.
Ok, using floats sounds a little strange, but maybe everyone's FPU are fast now-a-days, and who cares about ever running on hand held devices for the forseeable future, as the protcol itself will require a FPU to run well.
However, it is desirable for objects to be translationally invariant. As objects move to larger coordinates, IEEE floats will slowly drop bits of sub-pixel position information.
This is true, but you'll have quite a large number of pixels until the 23 bits bits of the mantissa (the 24'th bit is always one) aren't representing much sub-pixel positioning info.
The next question is how many bits of fraction to use. Four is enough for most applications, but eight will suffice for all but the most particular uses.
If 4 bits will do, I'd think that 2^19 pixels is a lot more than will be needed for some time. Even if 300 dpi flat panels come about in several years, and you must have 8 bits for subpixel location, 2^15 pixels at 300 dpi is still 109 inches!!
Well, that's enough nit-picking for one posting.
PJRC: Electronic Projects, 8051 Microcontroller Tools
What, without stopping to design it or anything? You'd end up with something that noone would use, or even worse, get entrenched with major design flaws...
Good engineering (albeit for an outdated requirement spec) is one of X's strong points.
I mean...motif on an older SGI is pretty fly. CDE on SUN boxes runs great...and those machines are using Display PostScript, which is slower than other models.
I want my windowing environment to respond NOW, when I press the mouse key...not after I do it...
Cheers,
C
- Sighuh?
Frankly, I think that MS is far behind Linux because they don't implement technology good enough. MS Windows users are where they get their money from, right? They deprived their userbase of certain technologies and implement them separately in each version of their operating system without spoiling the user with new features. That way, MS can brag about their product's new features! I've coutlessly heard already, "Pah! Pah! Look Pah! MS Windoze too-hundred-tousand had implmended synedric multie processin! waphooooo!" Along with, "eeeewwwww1!, phree hotmail 'n outook excess! 'cant wait to wun it!" I mean to say that MS is behind in the race, not Linux, not BSD, not Unix as a hole. Goodbye.(I am sniping a Micronics motherboard/w snd on eBay, using Lynx in about 5 xterms :o)
without prejudice
Nothing pisses me off more to see a windowing system highly dependent upon old school hardware techniques, when the majority of people are running something slightly more powerfull than my 2meg ATI mach64 I had until I bought a V3. (damn good card!)
I would compare it to software being written with 386 optimizations (or MMX) and completely ignoring all the new CPU instructions that would improve the speed of the software greatly.
There are always going to be a few people laging behind the crowd with thier hardware, they are called those with limited funds. But, why optimize everything to run well on thier machines and not take advantage of better hw if available.
I am convinced that the software development cycle is usually not taught correctly. Not nearly enough importance is placed on the idea of throwing what you have away when your feature set far excedes the features of the system it was engineered for. There is no reason to completely scratch everything, but much needs to be completely redesigned with the "new shit" (tm) that has come to light.
If we don't do that now, we'll be stuck with the same historic problems microsoft and others suffer from by having too much hacked together code to start over, yet too much hacked together code to continue adding features.
Slashdot needs to allow me to use ispell on my comments...
Spring is here. Don't believe me, look outside!
X is not *ugly* per se. Some of the window managers and themes are debatable.
However, the lack of anti-aliased fonts IS ugly. I know most programmers/sysadmins/"hackers" don't care, but too many web pages and word processing documents look like Commodore 64 screen captures.
I've never experienced "slowness" in X that couldn't be corrected by switching to a different window manager. Do KDE or GNOME run well on my 486? No. Should they? Perhaps. Does WinNT run on them? Absolutely not. In general, I think GUIs have gotten way too "heavy" these days. It's funny -- I hear more and more people wishing their desktops could be more like their Palm, not the other way around. We've had a lot of "do-everything-but-brush-your-teeth" GUIs, maybe minimalist interfaces are the wave of the future.
All the other gripes are, as you implied, pretty lame.
I'm guessing you're an ex (or current) Amiga user. This is how for so many years, despite inferior hardware, the Amiga managed to pull of some amazing graphics feats.
I seriously hope that the X team take your post _very_ seriously indeed.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Like, the scrollbars. Linux scrollbars are almost invariably hideous, probably as a result of the motif disease which infects everything. That's a tiny thing, but pervasive, and nobody ever bothers doing anything about it. And yes, i realize the scrollbars aren't handled by X or the WM. I don't care. Would it be that difficult to go and _make_ it so they are?
/' to get some text in your window. Now play with the scrollbar. See what I mean? The buttons have their own logic, but it's highly conterintuitive, and they can't even agree with the rest of the world as to which side of the window it belongs on! Aren't you glad every scrollbar doesn't work that way?
That would be a mistake. The designers of X wisely adopted a philosophy of "presentation, not policy" which meant basically that you could draw your scrollbars any way you wanted to, and X would allow it. Policy was layered on top of the window system in the window manager and in toolkits -- of which there are many today, including Athena, Motif, Qt, and GTK.
If the X designers had chosen to make policy part of the windowing system, then the only scrollbar today would be the Athena scrollbar. You think Motif scrollbars are bad? Have you tried an Athena scrollbar? Run an xterm. Not one of those new xterm-like programs but a real vintage xterm. Turn on the scrollbar. Run 'ls -lR
Some people have said that separating presentation from policy has led to mass confusion as the many different window managers and toolkits have tried to compete for acceptance with users and developers. Personally, I think that the abundance of WMs and toolkits have been a good thing, because it's meant choice for us, the users of X. Why should I have to use mwm or olwm when I much prefer Window Maker? Dictating policy and taking away choice is a hallmark of proprietary systems like Windows; X shouldn't try the same thing.
--Jim
Do you have a more detailed description on how you want this to work?
A good place to start is Newman & Sproul, Principals of Interactive Graphics - check out the section on scanline rendering. The Quake articles written by Michael Abrash are an excellent source, and they go into a lot of useful detail (some but not all of which is only relevant to 3D) To answer somebody else's question, no I'm not an Amiga user but this is just the obvious way to do it. And the corollary is, check out exactly how it was done on the Amiga (I haven't, I'm curious). If the shoe fits, wear it.
Does it increase the amount of memory needed by the server?
No. One of the nice things about scanline renderers is how little memory they use. Of course you can add buffering as an accelerator depending on how much memory happens to be available.
Does it increase the amount of network traffic needed?
It would have no impact on that: exactly the same render commands are sent by the applications. The only extra traffic would be for animation programs synchronizing with the refresh, and that would be miniscule.
How would it cope with for example a Netscape window that was 500 pixels by 100 thousand, which you wanted to scroll smoothly through?
The same way it does now: send a command to scroll the part that doesn't change, clear and redraw the part that does, run the part that goes off the screen into a memory buffer as memory permits. The thing is, all of the transfers to the screen actions would be delayed until the Netscape program says "go ahead and do it". Then all the renders are done, optionally deffering rendering for regions that are not visible, but retaining the commands in case they become visible, (so you don't have to ask the app to regen the region). When it's time to update the screen, you do one of two things depending on whether you have hardware accel or not. With hardware the renderer does a scroll blit and a put blit for the browser window, or multiple scrolls and blits if the window is broken up, but only for the regions actually visible. Without hardware you work your way down the region a line at a time doing the minimal thing to each line, which may be copying it from another part of the screen (slow) copying it from previously buffered data, or putting it from the new render region.
It's also nice to be able to work in an unbuffered mode where all drawing is direct to the screen and the renderer clips each primitive as it's drawn. Needless to say this is much slower and you get flickering, and implementing such clipping primitives efficiently and accurately is hard. But it's very helpful so you can see exactly what your program was doing when it crashed, or exactly why you're getting a messy blob when you should be getting a nice web page. Running the render in slo-mo gives you a graphics debugger.
I've never actually done all this (except in 3D rendering code) so I probably missed a few important points, but I think this is the general idea.
To put all this in perspective, run xpenguins or xroach and notice how much the rendering sucks, and think about what you could do about that.
--
Life's a bitch but somebody's gotta do it.
Why doesn't someone write X extensions for anti-aliasing and alpha? This sounds like an admirable short-term fix. Let XFree86 5.0 be a new system, until then lets have the modules. Anyone want to start some projects at sourceforge? (If I see no action on this I'll register one and provide links and what information I can; but I have to learn it first!)
Look at both Windows (GDI) and the old Postscript based systems. In fact look at the new system deployed in MacOS X.
What you notice is that the screen rendering system is integrated with the printing system so that, at least in Windows langauge, the printer is 'simply another device context to write to'.
It is crucial that the printing of documents, image, etc. to a hardcopy device is not left as an afterthought as it was with X. It should be simple for an application to say `print these to such-and-such a printer'. This requires that an X server have knowledge of other output devices besides itself, but this is not so stupid an idea. (The idea of X as a dumb display device should be consigned to its rightful place in the nearest dustbin).
John
John_Chalisque
I used NeWS when it was first released. It was a wonderful windowing system, very flexible and powerful. I saw at the time (1988?) that Sun was making an enormous mistake in withholding the source code to NeWS when X11 was freely available. Couple that with the fact that Sun did a lousy job of supporting their own product (they didn't release applications for NeWS, for example), it's no surprise that X11 clobbered NeWS in the marketplace.
I think I still have my treasured copy of the NeWS reference manual buried in a box someplace. Even now, over a decade later, X11 lacks features NeWS had, as documented by the article referenced from this Slashdot story. NeWS isn't commercially viable and hasn't been for many years; I wonder if Sun could be convinced to release the source code to it and see what could be done with in the Open Source world? (Nah, they'd insist on that abominable SCSL license...)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
X has a level of "acceptable mediocrity".
now where have i heard that before.
(note to people about to flame me: not that X is _bad_, just that it's one of the few things i'm aware of in the linux/unix world where something is in hugely wide use because of inertia and no other reason without any serious attempts at alternatives. (yeh, yeh, berlin, whatever) Yes, X is good enough, and the idea is nifty, but i have no idea why people put up with the fundamental shortcomings X does have so easily when these tend to be the people who in other circumstances demand the best they can get, and if they can't get it, write an alternative. Like, the scrollbars. Linux scrollbars are almost invariably hideous, probably as a result of the motif disease which infects everything. That's a tiny thing, but pervasive, and nobody ever bothers doing anything about it. And yes, i realize the scrollbars aren't handled by X or the WM. I don't care. Would it be that difficult to go and _make_ it so they are? would it be that difficult to make a concerted effort to go look at all the standard X progs you're likely to use and jam in GTK scrollbars? Why does nobody bother caring about these things in X? I'm too tired to explain these comments in detail or give examples, so i'm going to get flamed to hell and back. But i could go into greater detail and explain such things if i felt like it. And the article gives a great deal of examples of things in X-- fundamental things-- which are clearly no better than barely acceptable but nobody cares about. So go read that. And i'd add some to the list, such as having a "move this rectangle on the screen over ten pixels" type function that worked, preferably in the xserver's processing, but i dont feel like looking up and checking to make sure x doesn't do such things acceptably already.
The point is, X works, but you could have something so much better if "the community" just tried. But it won't. Well, let's hope Berlin actually gets somewhere. whatever, i'm going to bed. What was NeWS?)
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
- The performance on typical hardware can often be improved by giving it more attention in the driver. However, there is a fundamental problem here: the framebuffer resides across a slow bus (PCI or AGP), so you really don't want to push pixels one by one across it.
- Using e.g. textured quads and OpenGL's wonderful blending, alpha testing, and stenciling modes to express operations is not a nasty trick. If you want to blend two images together, being able to express that at polygon level rather than through tight CPU loops is elegant, not nasty! Also, it conserves bus traffic like crazy, and makes better use of the hardware on your graphics card.
- Doing graphics operations pixel-by-pixel using the host CPU is simply not what today's graphics boards (and machines) are optimized for. This might change in the future, but currently you have tens of millions of transistors in your graphic card's "GPU", so why not use them?
The last point above, that graphics operations today are best performed in very close vicinity to the actual graphics board, is basically what the linked article was about: moving functionality into the X display server makes it possible to execute it on the display hardware directly. This, in my opinion, is a very good thing.main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
Shine on, you crazy diamond.
So go code a solution. All I've been hearing is talk.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I believe this site summarizes the complaints against X (and a few other things) fairly well. There's a chapter on the X-windows disaster available in full-text. Even if some of it's claims are overexaggerated, it is still extremely amusing reading.
It's true that X is way out of date and needs to be improved. However, why should we settle for a few small additions (like cubic splines and transparency) to barely catch us up to today's technology? We discussed Aqua/Quartz, the new graphics technology developed by Apple (if you haven't read about it already, it's radically different than any existing system) and maybe we should all be moving towards something more like that.
Someone posted a concern that a new system would break existing X programs - but I doubt that would be a problem - if we switch to something new (and more powerful) we would just need wrappers that support the X11 API. I'm all for it.
Back in the days when I did a lot of Motif development, I always thought that the biggest flaw in X was how simple type-in fields worked. It seemed like such a waste of network traffic and server (or client in X11 lingo) processing when all you were doing was typing in a field. This is primarily what makes X11 unsuitable over the Internet.
What I was thinking would be really cool is to embed a Java engine in X terminals, and allow Java-based widgets to be downloaded. Imagine if this was in the core X11 protocol, and it was a very general object interface. You do all sorts of very cool -- very network efficient -- things.
Note that this doesn't break the X11 concept of "presentation, not policy". Policy would still come from the client program. The Java widgets would still be tied to the client program.
Java is not everyone's favorite language, but I think this is exactly the sort of thing that Java would be perfect for, particularly the platform-independent nature.
--
Sometimes it's best to just let stupid people be stupid.
AFAIK, this is one of the reasons Berlin started in the first place.
I'd love to see X speed up and keep up with the times, but I'm kinda afraid that the code may be too entrenched to make any serious structural modifications to this. I'm not an XFree hacker, so I don't know how much code modification what this guy is proposing would *really* take.
I do know that X works pretty well right now, and in the past, X people haven't been too willing to break the thousands of applications that are out there, even if it was The Right Thing To Do as far as architecture is concerned.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
I made a quick scan through your paper and it all looks right on the money. We need alpha; we need rotation; we needed zoomable/scalable/rotatable everthing.
I'd like to add a suggestion. 2D rendering is best done much like 3D software rendering: with something like a scanline renderer that makes one pass from top to bottom to render each frame, rendering exactly what needs to be rendered and no more. Instead of depth you have window priorities. Unlike a 3D animation renderer, you optimize for the fact that most of the screen doesn't change at all (so, to respond to another poster's remark - OpenGL isn't the way to go for 2D rendering - it carries too much overhead with it.)
Applications can know or not know about this frame-oriented rendering. If they know about it then can do really smooth animation by synching their erase/redraw cycle with the rendering cycle.
Advantages to be gained are: Software cursors that don't flicker; animation that doesn't flicker; video windows that don't exhibit strange behavior when you drag other windows across them; Scrolling windows that don't have little flickery blank spots at the top/bottom. And you get way, way more possibilities for optimization.
And don't forget this principal: when it's all done it should be smaller and tighter than X is now, even while doing 5 times as much. Because we had time to think about it and factor it correctly.
--
Life's a bitch but somebody's gotta do it.
'X is too ugly.'
X can be made to look any way you want it too look
It's not X its the toolkit
X is too slow.
Not over a network.
Its not slow, if you have good drivers for the
card locally. Especially XFree86 4.0
More than adequate to get work done
X is too old.
Unix is older. 1970.
X is bloated.
Name another protocol that works localy and over
a network, that takes less ram.
X is dumb.
that's a very personal opinion
X is stupid.
The proper response is no, you're stupid
what's so stupid about x
X isn't GPLed.
I'm going to assume you mean XFree
neither is sendmail or mozilla. there are alot of good non gpled projects. get your head out of your ass.
X has a difficult user interface.
X has no user interface. X enables you to build whatever user interface your want on top of it.
It has been statistically shown that helmets increase the risk of head injury.
SuSE is paying me to specify and implement this stuff. I'll have some demonstrations to show soon.
Nothing in this proposal will affect the way existing applications operate; X provides an extension mechanism which will be used for new functionality. Yes, this means that apps will need to change to get new functionality. Compatability bites.
This paper is being published as a part of the proceedings for this summers Usenix conference where I'll present a nice talk on the subject. They've requested that I make sure you all know who's publishing this.
Keith Packard
XFree86 Core Team, SuSE Inc.
keithp@xfree86.org