Slashdot Mirror
Gosling: If I Designed a Window System Today...
An anonymous reader writes "In his blog entry for the 10th August, James Gosling (finally) publishes a short paper he wrote in 2002 entitled 'Window System Design: If I had to do it over again in 2002'. His design is to make the window system do the absolute minimum and move all the work into the client."
I'd make it opaque to keep my arch nemisis, the Evil Yellow Face from entering my underground command center... though my mom alredy complains the basement is too dark.
He who laughs last is stuck in a time dilation bubble.
I think it is a good idea to separate the server and the client so each does its own stuff. This will increase modularity and compatibility quite a bit, IMCUO (in my completely uninformed opinion)
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
Why speculate about how Windows could be recreated with all the Linux distros that exist and the ease of any user rolling their own?
I defecated on my old Windows CDs and buried them in the yard. Sadly enough, when I told this to some Windows users, they actually mentioned that they wanted the CDs and asked me very seriously without a hint of joking, "can you dig it up?"
*snort* Sounds like a drug addict who will search through feces to dig out a fix. Sad.
blah, there's nothing written here.
Jay | http://oldos.org
His design is to make the window system do the absolute minimum and move all the work into the client.
2 3237&tid=201&tid=137
Wait, so you mean you wouldn't require this?
http://it.slashdot.org/article.pl?sid=04/05/04/22
So. Who's with me to create tihs sourceforge project? Dead serious folks, not a troll. BUt who has the gumption to get it started and make it run VERY fast, then after a while see how the X.org people would think of merging or using it? Eh eh?
let me know, use my gpg key to encrypt messages (it's the wave of the future!).
--zoloto
I can't count how many times I hear on /. someone saying that X is too bulky, etc, etc. And here's Gosling saying (2 years ago) that X is headed in the direction of slim and lightweight.
Am I misreading what he's saying?
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
First, it says he wrote this article 2 years ago -- talk about a slow news day for /.
Second, isn't this more or less what X11 is doing today anyways? Yes, the xserver is getting some new extensions added to it to handle things like compositing or polygonal shapes efficiently, but a lot of the cool new features we're seeing in applications come from userspace libraries on the client side of the X11 protocol. Cool little hacks like shadows or translucent windows are just the result of rendering a window off screen and using some compositing rules on the server for generating the final image.
Cairo looks like it will make a nice DPS-like library to use for graphics (it really looks like Postscript minus any programming language features which presumably get replaced by your own choice of language) and that hits Gosling's "postscript-like" display feature.
Is this just an attempt by him to say "told you so" or something?
Here it is..
Window System Design:
If I had it to do over again in 2002.
James Gosling
December 9, 2002
In the deep dark past I have been involved in building window
systems. I did the original design and implementation of both the
Andrew and NeWS window systems. Both of which predated
X11. They shared with X11 the architectural feature of being
networked: clients sent messages to the server over TCP
connections. I occasionally get asked "if you had to do it over
again, what would you do? Would you do the same thing". The
answer is a strong no. It's now 20 years later, and the
technological landscape is totally different. So here is what I
would do. But first...
The term "window system" is somewhat loose. It generally refers
to the mechanism by which applications share access to the
screen(s), keyboard and mouse. Beyond this it generally contains
facilities for inter-application messages such as support for cutand-
paste, and drag-and-drop. It also often contains support for the
decorations surrounding windows that provide the user interface
for resizing, opening and closing windows; although in some
systems this has been left up to the application. Sometimes the
window system provides higher level abstractions like menus.
When a system is designed, there are always tradeoffs made that
reflect the technology of the day. In the case of Andrew and
NeWS, these tradeoffs were based on the state of the art 15 to 20
years ago (this probably applies to X11 too, but I wasn't involved
in the design analysis behind it). There were a number of things
that were very different between then and now.
1) The most significant is the relative performance of graphics
rendering and network communication. Back then,
rendering was relatively slow. The overhead of network
communication was significantly overshadowed by the
overhead of rendering.
2) Back then, there were no shared libraries. This seems odd,
looked back at from today, but back then no version of
Unix had the ability to have a library like libc or OpenGL
that was shared between processes. All applications had to
be "statically linked". There was a primitive segment
Background
History
sharing facility that allowed one segment per process to be
shared, that was at the beginning of the address space; but it
wasn't powerful enough for this purpose.
3) Putting large things, like windowing libraries, into the
kernel is generally a bad idea. It has a significant negative
impact on the reliability and testability of the system.
4) When hardware acceleration was available, it generally had
no interlocking mechanisms for arbitrating amongst
independent threads that were trying to use it. This
generally meant that either the accelerator was permanently
allocated to a thread (very common, since acceleration was
normally 3D hardware used exclusively for CAD), or there
was an software interlock mechanism that added some cost
to each operation.
So, given these, where do you put all of the code that is involved in
the window system - including the graphics rendering library?
Remember that rendering libraries tended to be large, since
hardware acceleration was almost non-existent.
They couldn't be in each user process, since without being shared,
they would take up an unacceptable amount of RAM. So the only
way to get one copy of the code, and have it outside of the kernel,
was to have it in one process, and to have applications
communicate with this "window server".
But today, while putting large amounts of code into the kernel is
still a bad idea, rendering performance has improved dramatically,
and most operating systems have shared libraries. The increase in
rendering performance has outstripped Moore's law, which in turn
has outstripped the increase in generally available bandwidth,
making the overhead of shipping requests through the network an
unacceptable burden.
High per
But someone mentioned on Slashdot actually implemented what sounded to me like a pretty good idea. They used the structure of XML to transfer data between client and server.
It makes sense, if you think about how graphical elements are grouped and have properties...
tasks(723) drafts(105) languages(484) examples(29106)
One problem is his treatment of remote windows... He suggests sending them over as video streams.
If networking bandwidth is a problem now with the X format (which is basically just sending clicks and so forth), why does he think the response is going to be any better when sending *a huge ton of pixel data*?
Even if you assume that you only have to transmit differences, there are still cases where the difference will be several megs. (For example, a fullscreen clear in 1600x1200x32).
I currently have no clever signature witicism to add here.
His idea of making remote connections a highly compressed pixel stream doesn't excite me - it seems less than ideal.
I would think that you would want to stream, when possible, rendering api calls, so that you can send pixel data as pixels, vector data as vectors, and 3d surface and texture data as such.
Maybe have a method for negotiating what rendering api's are supported, stream those, and then render the rest as pixels and push those.
My intuition tells me that doing so would make remote connection streaming a lot more efficient. Maybe someone with more knowledge than me can explain why this would/wouldn't be a good idea.
Inconceivable!
As Gosling mentions, X is moving in this direction today. In a year or two, when the newest X changes are stable, the average GTK+ or Qt app will talk to the server via OpenGL. On most DRI-like setups, the route from GL to GPU looks like:
OpenGL -> userspace command buffer -> graphics memory (DMA via Direct Rendering Manager).
Text layout, fonts, etc, are all done server-side, and the only thing the "server" sees are pixmaps and GL commands.
A deep unwavering belief is a sure sign you're missing something...
People who complain about X being "bulky", "bloated" and all that are trolls. It was designed on slim hardware and designed flexibly.
The real test is to simply use it. Try Feather Linux or any of the other tiny distros out on some crufty old hardware and see for yourself. I've got a 90 MHz laptop that runs X just fine with 24MB of RAM thanks to Woody, fluxbox and other light applications. Gnome 1.4 also is snappy enough, though KDE is a little slow. X is not the problem if there is one! Feather runs even faster running testing and unstable Debian code and I suspect that two further years of going down Gosling's path is responsible. Of course newer hardware runs better and I don't have problems with things like xawtv, Xine or quake running with KDE or Window Maker on top of X.
From where I stand, I have no idea what people are talking about when they complain about X. They never say anything specific.
Friends don't help friends install M$ junk.
insecurity asks the wrong question irritation gives the wrong answer
X has it's flaws. This sounds good but doesn't have any implementation. But we seem to forget about our little fledgeling, the Y-Window system. I'm sure they could use some help.
Can't your poor Lunix handle PDFs? Get a real OS, hippie!
g system. I mean, seriously. I'd understand if someone from Apple was talking about this stuff, but looking at Java, especially the parts in any way related to the UI, I can't help but wonder just how badly a company can shoot itself in the foot. The only reason why we're not seeing tons of Java apps everywhere is because of this moronic and slow Swing library.
Maybe its because Gosling is coming from X11 land and its sucky drag n drop/clipboard implementations but this is seriously a big deal is a Windowed operating system. In a Windowed Operating System, it should be easy to move data from one application to another---even though they are made by different companies. And not just text either---things like pictures as well. Going beyond this, dynamic linking and embedding is a handy feature as well.
Does this mean that Rasterman and the Enlightenment crew are going to have to re-impliment Enlightenment DR17? Maybe next year will be the year of E... but no matter, doing the job correctly is more important than rushing a release. Still I wish they could get sponsored or something to speed up their developement. How long has it been? *sigh* and no, I'm not even a [great] programmer, that's why I have to make such a silly comment to begin with...
...that gives me an idea.
Run an X server on (insert your preferred platform), then run your X client apps on each of the platforms they're needed on. Be it Linux, Win32, OS X...whatever.
tasks(723) drafts(105) languages(484) examples(29106)
A system where the client simply sends a command to the server like "ls" or "cp x y", etc. The client is free to display it however it wishes.
One could implement a web client file manager (with Flash or some future SVG thingie or whatever).
Go buy yourselves a decent computer.
Seriously, all we are talking about is modularizing the windowing system. If the WS is as simple as possible, people are going to rely on libraries and windowing toolkits to get their work done. I guess that's already happened with GTK, etc.
Computers are useless. They can only give you answers.
-- Pablo Picasso
"His design is to make the window system do the absolute minimum and move all the work into the client."
This is ridiculous. Look, ALL modern software has gotten so incredibly bloated and complex that it's just a joke. What we need is a windowing system that adopts the concept of Apple's old "toolbox"-- windowing functions and basic graphical functions AS PART OF THE CORE SYSTEM-- without the horrible kluge that I've heard "classic" Mac OS coding was. The concept was nice, though.
Look at GNOME, KDE, Windows XP. It's fucking ridiculous. How many fucking library dependancies do you need for a modern windowing system? Have you ever run 'ldd' on a modern GNOME or KDE app? It's enough to make you vomit.
It shouldn't have to be so fucking complex. The windowing system should offer basic 2D and 3D functions, widgets (file selection boxes, drop-downs, radio buttons, checkboxes, crap like that), they should be efficiently and tightly coded (preferably in C, with some ASM for speed on common architectures, and in the most CPU-intensive crap like 3D).
Look at what the Amiga was able to do with a 680x0. Sure, it had some custom chips too, but it was still a 680x0-- and modern CPUs are so fast that those extra chips are no longer necessary. With an old Mac Plus, it would take maybe a minute to boot up System 6... and with a modern Windows XP or RedShat/Fedorka box, it takes... maybe a minute. And this is progress? Also, most programs for System 6 required how many libs? Count 'em... YES, THAT'S RIGHT: ZERO! They simply used Toolbox calls, and any functions that were needed beyond that were not so hard to include right in the binary itself.
Simplicity, people. What we need is simplicity. For most tasks, a P4 running XP "feels" no faster than a '386 running Windows 3.0 in '386 Enhanced Mode did.
And that is sad...
Honey, I shrunk the Cygwin
it would have a control panel, and every app would have to register with it, so it's all central (of course they can link to their part of it from tools>options or whatever. There would be one toolkit, so everything would always look the same. there would be a quicklaunch menu like on windows, where the overflow becomes a menu. There would be good support for hotkeys, drag and drop, and an overall common look and feel. I think windows comes closest to this, but the lack of the ability to theme explorer without hacks sucks, and of course it's windows. I wish someone would write an explorer clone for linux.
Amen.
For my fellow Amigaites out there:
*sniff* That brings back memories. Sadly, my Amiga RKMs now support my monitor, but oh... this is so familiar. :-)
For the rest: the Amiga had a graphics library layer that talked directly to the hardware. On top of that was built the "Layers" library which does what Gosling is talking about. It just handled clipping lists and "stacking" without any other details. On top of this layer was built the GUI.
Also, the Amiga used a single message port to communicate with the application. You could have more msg ports, but rarely needed it. You waited politely for a message, fetched it, then acted upon it as you will. All your GUI events queued up nicely in the message port.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
Since the advent of Quartz Extreme, the "clip list" should be a thing of the past. There's no application level support for clipping. There's barely Kernel support for CLipping. It's all 3-D graphics card clipping at this point. The "refresh event" should be a thing of the past by 1996, much less 2004, despite any Plan 9 patents.
Clip list for mouse events, sure. But for screen refresh? In 2004? I thought this was already a dead issue!
XCP - the XML Control Protocol
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
Gmail's interface is an interesting design, hiding away functionality until you need a specific feature.
I always wondered if a generic window system could be designed in the same modular way, with smart application modules anticipating your behaviors and adding more and more specific, functional components into the UI as you perform a particular task.
In order to get good performance out of such a simple window system, applications need to be reasonably intelligent. One thing I think this entails is getting rid of immediate-mode APIs as the standard way to draw, and make retained-mode APIs the standard way to draw. To refresh your memory:
- An immediate mode API is something like GL or Cairo. The app sends drawing commands, and the engine executes them immediately. If something moves and needs to be redrawn, the app musdo all the work of redrawing the scene.
- A retained-mode API is something like EVAS. Instead of submitting drawing commands, specifies what the scene looks like in a scene graph. The canvas library does all the dirty work of redrawing scenes efficiently when things change.
The plight of X (which has very fast drawing, but often has brain-dead application redraw behavior) shows that no matter how fast your graphics API is, many application programmers (who usually aren't graphics programmers), will still make it look slow by writing apps that redraw the whole scene on even the smallest change. A good canvas API like EVAS fits very well with how most apps work. Canvas APIs are slower when scenes change quickly, but for most apps, most UI elements stay static. Where canvas APIs excel is in allowing simply-coded apps to demostrate good redraw behavior, because all drawing optimization can be done in the canvas.
Of course, for scenes which are animated and quickly-changing, apps should be able to access the underlying immediate-mode API, but this hsould be the exeception rather than the rule.
A deep unwavering belief is a sure sign you're missing something...
he also says that (a) sending pixel data is basically what the Sun Ray product does and (b) it's about as efficient as using the X protocol would be, or (reading between the lines) they wouldn't have done it that way...
with XHTML.
You're an idiot. Gosling had almost nothing to do with Swing, which came out a while after Java had already become big. If anything, he might have had a hand in AWT.
... could you take a wee break between engines and do an Id OpenGL GNU GUI?
Words to men, as air to birds.
I feel like I'm responding to a troll here, but I think you haven't used Swing in a while. The latest releases in 1.4 are significantly better looking and faster. They also make better use of the underlying graphics hardware in Java 2D. I've written apps in Swing that have been very responsive; you just have to take the time to learn the framework.
I will grant you that Swing can get complex and it can take serious effort to eliminate bottlenecks. It's intended to be a general framework for MVC based applications, so it has to cover a lot of cases that may not be applicable for all applications. You sometimes have to subclass and override default painting behavior to tailor it to your usage. But at least you have the ability to do that if you wish.
It also has a tendency to be lower-level then some other approaches. I've seen people throw together VB apps with a lot of functionality pretty quickly. It can take longer to get there in Swing, but the results generally are more maintainable and scalable.
There are efforts in the works to generate standard higher-level constructs, such as database-backed tables with sorting, that other GUI frameworks provide. Check out JDesktop Network Components to see what's in the works. There are also efforts underway to allow Swing apps to fit more neatly into the native shell (such as tray icons).
Swing was pretty deadly in the past, but it has improved significantly recently. Ironically, I'm seeing a lot more MacOS X apps written in Java or Java apps developed on MacOS since Apple has put a lot of effort into their Swing look and feel for Aqua. If you are looking to Apple for direction, I think that is a significant data point.
======
In X-Windows the client serves YOU!
..But then what will I make my hat out of?
...what do you think of a person who only does the bare minimum?
Sigs for Nerds. Sigs that Matter.
Since the advent of Quartz Extreme, the "clip list" should be a thing of the past
For whatever it's worth, this was written just a few months after Quartz Extreme become available to the public in Jaguar 10.2.
- Scott
Scott Stevenson
Tree House Ideas
He is mostly right.
The one problem is there though: by using lots of client side libraries with their own per-client state some efficiency is lost and startup time increases greatly.
We are already seeing this with today's gtk and kde programs that already have disastrous startup times.
[mark@silver mark]$ time xterm -e exit
real 0m0.111s
user 0m0.066s
sys 0m0.007s
[mark@silver mark]$ time gnome-terminal -e exit
Bonobo accessibility support initialized
GTK Accessibility Module initialized
Atk Accessibilty bridge initialized
real 0m0.311s
user 0m0.203s
sys 0m0.032s
[mark@silver rxvt-unicode-3.3]$ time src/rxvt -e exit
real 0m0.052s
user 0m0.004s
sys 0m0.003s
The machine is Athlon XP 2500+ 1G RAM, no swap, Fedora Core 2.
If I had the chance to do it, I'd call it Lindows.
Logic, macros, and more
In the Mac OS X window system, there's still clip lists, but they are not visible to the application. The app just draws in it's window buffers.
The clips are needed to handle event routing, as you mention, and to take care of some subtle internal housekeeping, even when Quartz Extreme is in use. Since not all systems or graphics cards can run Quartz Extreme (there are certain specific graphics card capabilities needed) the clipping information is needed for software compositing cases.
No, but I have read your referral ID that's hidden in your signature's link (hello "ase_datadino-20"). And I'm electing to respond rather than mod you down for this sleazy behavior, since this reponse will hopefully get you modded down to -1.
Why does it remind me so much of directFB?
"My logic is undeniable."
I have two quotes because I heard both of them in person[1]:
1) "...people don't want bug fixes, they want new features."
2) "...I don't care what the Information Superhighway looks like as long as I have a toll booth on it."
[1]This shoud help alleviate the FOAF|UL factor.
____________________
My Trunk Monkey can beat up your Trunk Monkey.
The last thing we need is a new design that allows arbitrary user programs to have read/write access to the entire screen (read-only access is bad enough). Sooner or later, we are going to start running arbitrary programs on our computers in a secure sandbox environment that is enforced by the OS (and ultimately, the CPU). What happens when some cute little game your spouse downloaded yesterday decides to make itself look like your electronic banking program? Under this architecture, how do we avoid that? Hack every display driver in existence? Trust the shared library to prevent this?
I guess you never heard the NeWS have you?
Pan
I said no... but I missed and it came out yes.
sounds a bit like describing the OSX window system, extremely minimalist, and the drawing is done on the client side
If I designed a window system today, it would have themeable standard widgets, and the protocol (function calls for local, some sort of RPC for remote) would only have to specify the widgets to be used, as opposed to all the drawing operations, which is what X11 does.
...) to be communicated between server and client. Rather, clients would be able to indicate which events they wish to receive for each widget (basically like onclick, onmouseover and friends in HTML).
Also, it wouldn't require each and every event (mouse move, click,
All this is simultaneously going to do away with the many competing and incompatible GUI toolkits for X and the non-themeability of Windows and Aqua, and make network transperency work without huge bandwidth requirements and sluggish responsiveness.
It's worth pointing out that this window system exists in the form of PicoGUI. Sadly, the site is currently down.
By the way, what is it about OpenGL that makes it so suitable for acceleration, yet it's horribly slow when implemented in software?
Please correct me if I got my facts wrong.
try running complex X apps (like openoffice, mozilla) over a slow WAN link.
it's intolerably slow, because of all the rendering api calls. even (seemingly) simple apps become pure torture. if a window becomes obscured and has to redraw, you'll want to put your fist through the monitor.
now run the same app via something like vnc. it's no longer totally unbearable. it's actually usable.
gosling is quite right on this point. it's far more efficient to just stream it as (compressed) video data when you have to talk over networks.
god, fucking slashdot clearing my post on previewing, no other site does that...
fuckit, suammary:
Windows already does all this.
Now go do it in an Open, non-patent encumbered way.
I know this is getting a bit off-topic, but I've been pretty impressed with swing latly. Which is pretty amazing considering swing is the reason I stopped coding in java about three years ago. Since then I've made a modest increase in ram (just from 128 to 372), and upgraded to the 1.5 jvm for linux. I don't know if it's the additional ram, the jvm, or a combination of the two, but the swing applications I've played around with are almost exactly as responsive as gtk2 programs. That, combined with potential for also allowing an option to use real gtk2 from SwingWT finally managed to make me look into Java for the next project I'm working on.
Everything will be taken away from you.
I'd make the windows group by process tree, and offer frames of grouped windows, panes of subwindows, and visual pipes for STDIN/OUT/ERR among them - all embeddable among one another. I'd save window geometries in an OS DB. I'd strictly define the windowing system as merely the presentation layer, independent through an API to a logic layer, in turn independent of a data layer. And I'd write the entire windowing layer in OpenGL.
--
make install -not war
I was thinking along these lines a few years ago, when I did some work with the GLOW toolkit, which offers a portable GUI built on top of OpenGL. Once 3D hardware got reasonably good, that approach worked fine. It was clear that much of the complexity of existing window systems was now unnecessary.
The main job of the window system at the OS and graphics card level is protection - keeping each application locked inside its own windows. Everything else, as Gosling points out, really should be done by the application.
More important, though, is that it is time for window systems to become real time. You should never wait for the window system, and you should never see any artifacts of the window system. Any card that can run even older video games can do this.
Letting the app take care of its own window borders is a bad idea as well. This is one of the worst parts in M$ Windows - once an app hangs, there is no way of closing or minimizing a window or simply of getting it out of the way. It's way better to have this handled by a separate process.
open (SIG, "</dev/zero"); $sig = <SIG>; close SIG;
Or at least were involved with it. Andrew, which I have never used but were "talked about" a lot, and NeWS which was simply amazing, but unfortunately was marketed after X10 (and later X11) has become the de-facto standard for Unix desktops.
Not fair to blame Gosling for Swing. He mostly participated in actual Java development back when Java was still called Oak, and was still viewed mainly as an embedded systems language. Swing didn't appear until after Sun began its big push to sell Java as a general-purpose platform. By then, Gosling had been promoted to "Chief Scientist", a job that seems to consist mostly of giving speeches and writing papers.
Moderators take note, please: anything Mike Paquette posts on Mac OS X should be moderated +10, Reference.
Thanks,
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
If I designed an $X today, it would be built with nanobots and turn the Earth's surface into a gray goo.
Later some small robotic rovers will come by and say "Holy shit it look like there used to be water on this planet!"
To have consistent looking application you still need to do everything in the server. Adding more layers like is now happening with X and GTK or one of the other packages, is one way of doing that. And moving this to the server instead of the client makes it all abit faster because less data has to be moved long distance
Seriously, the guy is basically the computer anti-christ from Revelations.
He comes and people proclaim him the savior, only after everyone has been well marinated in the OO KoolAid(tm) do people realize, damn we've been had, this whole this sucks, is not productive and the prophesied code-reuse never happened.
It turns out the drunken monkey fulfilled the code reuse promise.
If I ever met the guy, I would beat him within an inch of his life for all the fucking extra work I've had to do to pull these Java-Only idiots through even the simplest troubleshooting or development tasks. Oooh! Java is so great - good then learn how to open a fucking socket listener and handle a few connections.
Sorry, I'm very bitter from doing all the work while a team of asses sat around complaining that there was work to be done and collecting a salary.
From the Article:
<i>Once you accept that fact and admit that
it’s actually the right way to go, the design falls out, simply by
stripping away legacy stuff that isn’t needed any more.</i>
This is actually the hardest thing to do. Todays Computer systems ar still mostly based on the concepts of 30 and more years ago. So many things that got hacked in into Unix and/or Windows in the last decades could be unified in the way it is accessed. Plan9 is actually a nice step in this direction.
Just because I can imagine doing a hippopotamus, doesn't mean I'd like to do it.
(1) X/gnome/kde does not behave exactly like Windows. Peoples will always blame the new behavior.
(2) Peoples are not using the proper drivers. Open-source NVIDIA drivers are a lot slower than the proprietary one.
(3) The Window manager and the applications are not synchronized so most WM managers eat all the CPU during opaque resizing. The faster your mouse send the motion events, the worse it becomes because the WM might end up redrawing the borders hundreds of times per seconds.
The advantage of having a WM is that windows controled by non-responsive applications are never stuck in the middle of the screen like in Windows.
(4) Peoples use fancy themes with gradients. XFree does not have any efficient way to draw gradient so they have to be rendered off screen and transfered to the server. It is diffficult to cache gradients because their content depends of several factors so most theme engines do the offscreen rendering each time.
The gradient problem is probably the only one of those issues that could be blamed on X/XFree86.
All modern graphic cards can do hw gradients, so an efficient X extension would really speed up things.
Actually, what he's describing sounds a lot like DirectFB. Take a look at : http://www.directfb.org/
It's library that interfaces the Linux kernel framebuffers and hardware acceleration directly. At the moment, supports Matrox cards best (with partial support to ATI Rage and S3 and others.) The application suite includes X11-implementation and SDL programs should run directly.
I tried it a while ago but switched back to X.org. (Switched G400 to R9200 too.. UT2004 needed more kick.)
My level of understanding on this is pretty low, but what differentiates DRI from SHM and DGA?
----- Question authority, but not ours. Hate the man, but we're not him.
XML has its problems, the main one being the characterset representation which makes it so verbose. There is a variant called WBXML, which was designed for WAP based mobile phones (i.e., limited bandwidth). With this form you can considerably reduce the size of the XML and also ease the parsing process.
It is called MS Windows and DirectX.
hopefully he'd notify the user that it's not a normal link. basic stuff, really...
On the face of it this is the almost the same thing.
Try running blender under just the raw X, blender handles its own environment as is suggested in the article. (im sure there are other examples too).
If you think about it you will realise that your favorite window manager is just an application that handles its own environment.
Actually whats really left at the end of it all is that his Windowing system, isnt a windowing system at all, rather an ultra basic framework that handles only the minimal requirements, that provides a basis to build windowed applications atop. Rather like the philosophy behind the X server really.
Electronic Music Made Using Linux http://soundcloud.com/polyp
But now is too late for Java. It already has a reputation. Nobody I know considers Java an application language, and it's primarily because of it's GUI - non-native widgets, and slow response. Even if it's now improving, and it is, it lost the lead, and its gonna be tough for it to play catch-up.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
I waste more time blowing my nose.
You'd be amazed how much better you can do with a little practice.
Since he's a Mac OS X user, he could have used Trapeze to drag and drop convert his PDF to HTML. If he had to do it over again, of course.
Neither of these features is the responsibility of the windowing system. A windowing system only records events and distributes them. To the windowing system a drag and drop is a click, a mouse move, and a declick and nothing more. All the windowing system does is alert through messages, "Hey, a click happened here", "Hey, the mouse is dragging", "Hey, the mouse was declicked." The application is responsible for knowing what those events signal. The application is responsible for interpretting the results, and for converting data from source to destination.
The same is true of cut and paste. The windowing system sends only the events. An application at a higher level is responsible for actually transfering the data. The windowing system might offer facilities for locating the source of the data, or notifying the destination to pick-up the data, but the windowing system neither knows, nor should it care, what that data is.
Linking and embedding, needless to say, is also the responsibility of the application. The application has to recognize that the data transfered is an object, load the appropriate embedding library, and make the causal link between the two.
The practical upshot of the above is that one should not confuse the functions of the windowing system, which are to arbitrate access to user interface devices and screens, draw upon those arbitrated screens, and transfer events with the functions of the application. There is nothing to be gained by burdening the windowing system with the application tasks and much to be lost in terms of flexibility.
-if he designed windows today he would do what everyone else is doing already.
-therefore windows must be stuck on legacy ideas and structures that cant be changed even in new versions because everything else would break
-or windows developement has gone stale and each new version of windows is just a patch on the previous one..
This comment does not represent the views or opinions of the user.
His new design duplicates the big mistake of X... putting policy in the application... and makes it worse. Why is it that people use Mac OS or Microsoft Windows? Because they have a consistent GUI, however it's implemented, that isn't subject to the whims of each applications programmer.
And it's unnecessary... most applications need a fairly limited set of graphic primitives, and where composition of those primitives is needed scripts in the window system can virtually always do the job: the limiting factors in a GUI are rendering, which would still be handled in native code, and the human. Yes, some applications need tightly coupled high performance control over their display, but this is still and for the forseeable future an exception. Even art software really doesn't need the kind of GPU-intensive performance he's shooting for. The applications that need to do their own direct rendering of complex scenes, rather than just a fast way to pump bitmaps to the display, are pretty rare and can be dealt with as they are now with a shortcut through the window system. With OpenGL you can even have multiple applications of that kind running concurrently without interfering with each other.
So the special case he's optimising for is already well handled, we don't need to build the window system around it. And in the general case it wastes the performance of the graphics card by keeping the application way off in the processor intimately involved with the mechanics of moving images around. As GPUs get more power and memory it will be more and more practical to move more of the window system into the GPU, and it will be more and more desirable to handle rendering in a common layer that's close to the display (in the GPU, where possible) the way Mac OS X already handles compositing.
Quartz Extreme is pretty crude. It shouldn't be necessary to do rendering in the processor and compositing in the GPU (the normal case, because it doesn't copy rendered windows back from the GPU to the CPU and maintains the master of each Quartz window in main memory at all times), with all the extra memory traffic that creates... but it shows the way forward. A truly 3d GUI where windows and more complex application objects are managed in 3d space the way a window system handles them in 2d space should be possible and efficient.
But consider what happens when you move a window into the 3d background... the GUI moves it away from you and tilt s it at an angle so you can keep it in view "off to one side". You can't keep going back to the application over and over again to re-render its part of the screen as your viewpoint changes. Instead you let the GPU map it onto a surface, and navigaton of the environment is smooth and more or less invisible to the application. Perhaps one might send the app a signal that say "suspend updating" when it's too far away or out of your viewpoint, but that's an optimization.
No, this is exactly the wrong time to go back to the X model of a dumb server and smart applications.
From the article:
These days it's becoming required to implement double buffering. For anyone who's ever used OSX, the experience is totally addicting and quickly become a non-negotiable feature
I believe Windows XP has this too; you pass WS_EX_COMPOSITED to CreateWindowEx(). Sadly it's not the default... does anyone know of a way to force all windows to get this flag? (Aside from some gross hack like replacing user32.dll, or installing a CBT hook and calling SetWindowLong(hwnd, GWL_EXSTYLE, GetWindowLong(hwnd, GWL_EXSTYLE)|WS_EX_COMPOSITED) for each window created. Hmm, perhaps I'll go try that.)
Java: the COBOL of the new millenium.
Do you think it causes harm for the application to know which regions of its windows are exposed? I agree that it shouldn't be necessary, but at the same time, it is nice to avoid speculatively drawing things which the user can't even see.
Java: the COBOL of the new millenium.
You know? There's ways to get around the verbosity being a problem. But since you all are bloody geniuses, I'll let you all figure it out.
let's all just go back to 80x25 ASCII graphics with green or amber displays and just good ole dos or linux command line. Then it should only take a few seconds for a system to boot up.
Besides, if you need a GUI, then you're too stupid to use a computer.
This is actually exactly how Qt/Embedded works :)
--
(I used to be jo@trolltech.com)
Microsoft Office isn't preloaded into memory on bootup. This is yet another false Slashdot meme that gets regurgitated over and over until it becomes "fact." At most, all Office ever did was automatically run a quicklaunch bar at the top of the screen. I don't even see that around anymore.
And the fact that Office apps are mostly loaded into memory at boot, thus providing the illusion of speed when they're 'opened', hasn't been pointed out to you?
And the fact that that's not true hasn't been pointed out to you? Yet, I fully expect to see ignorant people repeat this false idea again in the next Windows discussion.
It's called Y-Windows.
Stuff that's nearly two years old.
My car gets 40 rods to the hogshead, and that's the way I likes it!
Sorry, but Microsoft says you're wrong:
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Not posting if you are a fucking moron?
From the very page you link to:
The Office Startup Assistant (Osa.exe or OSA) is a program that improves the performance of Office 2003 programs. Office Setup no longer puts a shortcut to the Osa.exe file in the Windows Startup folder as do the earlier versions of Microsoft Office.
I haven't seen Office Startup Assistant in the Startup folder since using Office 97 in college.
Well, no, you should not try that on a P90, but that's not X's fault. I doubt a svga version of quake or xine would work well either. The basic rendering system is what's OK. It delivers fonts and graphics good enough for most purposes. Text editors, email, reasonable web sites and Gimp all work well, so my 8 year old laptop is still useful.
Friends don't help friends install M$ junk.
Friends don't help friends install M$ junk.
The plan 9 way of doing the windowing system is very interesting. The way /dev/bitblt is handled is probably the nicest way to implement a windowing system...
An intro to 8 1/2
No, in this and most other cases, the troll says something like this instead:
At work, we have about 400 Sony Vaio laptops with maxed-out RAM, and Firebird and Opera are too slow to use because they swap continuously ...
My 233 MHz P2 with 64MB of ram renders the web just fine through KDE3.2 with a default Debian Sarge install. X seems to do just fine supporting all of that, so I still have no idea what you are talking about. What kind of hardware are you running 400 of that's more pathetic than mine?
You know, AC, I think you are lying.
Friends don't help friends install M$ junk.
He's talking about Pelor! But Pelor's not evil...he's Neutral-Good.
tasks(723) drafts(105) languages(484) examples(29106)
Whenever I see someone oushing to make a new X without the networking as part of the base functionality because it's not used all that much, I wonder if they've done their research. I use it daily, and I'm just your average hobbyist. It's one of the things that I miss in windows. (No, VNC is not an acceptable substitute.)
Startup time was basically instantaneous - from the command line, you type "8 1/2" (in Unicode :-), hit carriage return, and the window system was up and running in about the time you'd expect to wait for shell to give you a $. I think it was about 64K lines of C code. This was running on a Next pizza box workstation, so it was a 68040 at probably 33 MHz - nice for its day, but not blazingly fast. The screen was 2-bit grayscale, which is fine for software development though obviously it'd be nice to have something a bit fancier...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The TK part of TCL/TK is another canvas-based approach (also usable as TKInter from Python).
- James Gosling wrote the NeWS Network Extensible Windowing System.
- Don Hopkins was one of the absolute wizardly programmers using NeWS.
- JCR was a NeXT Weenie, and is now an Apple Weenie. (I forget if you worked directly for NeXT or only were a heavy user...)
- The Unix-Hater's Handbook was written in the late 80s, so the comments mostly relate to X11R2 or thereabouts, and when Don was referring to a 486, that was a fast computer. I thought the book was misnamed - it was largely the sendmail- vi- and emacs-hater's handbook, and many of the things that were evil about Sendmail, Vi, and Emacs then are still evil today.
So when Don was ranting about architectural choices that were wrong with X, he was comparing it to more interesting architectures like NeWS or various experimental things that have been left in the past, or to Windows which was relatively lightweight (though badly buggy) back then (the "lightweight" part has since been fixed.) And the things that he complained about mostly haven't changed a lot, except that Motif was really bloated back then, while these days Gnome looks bloated (but does a lot more) and Motif looks comparatively lightweight.The one major difference is that today, the main uses for X are to run a browser as well as Xterm. To some extent, this balances the really big advantage of X (or NeWS) over Windows, which is being able to access resources on lots of machines at once.
What Don *didn't* rant about, because he was ranting about X, was that NeWS had its own horribly broken tradeoffs as well. The way it implemented really good WYSIWYG rendering and let applications decide which pieces of work should run on the client vs. the server was to pass executable chunks of Postscript code around for the interpreter on the NeWS Window Server to run. When everything worked, it was excellent, a joy to work with, and received the kind of raves that NeXtStEp enthusiasts give NeXt'S environment, but it had an almost total lack of security between applications, and if anything broke your screen tended to explode into an angry fruit salad. There were few people capable of doing real debugging in this environment, though Don, who was one of them. wrote an amazing debugger for it.
Java took many of the good ideas from NeWS about letting you safely hand chunks of code between cooperating interpreted processes, but did so with an actual security model built in from the beginning. There are people who don't like it (especially ObjectiveC fans), but one of its worst problems, slowness, has been fixed in part by JIT compilers and in part by Moore's Law. Unfortunately, some of Java's competitors, like ActiveX and JavaScript, didn't have a solid security model built in to them, so while they also let you divide labor between clients and servers, they're a security nightmare that could, and should, have been avoided.
Disclaimer: JCR and Don are friends of mine. I've met Gosling occasionally, but it's been a few years.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Oh, you're not? Then where did you pull this assertion? Out of your ass?
Thought so.
This is to inform you, gentle moderator, that the parent post is from a person who has trolled Slashdot in the past under the names bonch and Overly Critical Guy. Please, do all of us a favor and don't be taken in by this person's moronic brayings.
Thank you.
This has been a public service announcement.
This is to inform you, gentle moderator, that the parent post is from a person who has trolled Slashdot in the past under the names bonch and Overly Critical Guy. Please, do all of us a favor and don't be taken in by this person's moronic brayings.
Thank you.
This has been a public service announcement.
This is to inform you, gentle moderator, that the parent post is from a person who has trolled Slashdot in the past under the names bonch and Overly Critical Guy. Please, do all of us a favor and don't be taken in by this person's moronic brayings.
Thank you.
This has been a public service announcement.
This is to inform you, gentle moderator, that the parent post is from a person who has trolled Slashdot in the past under the names bonch and Overly Critical Guy. Please, do all of us a favor and don't be taken in by this person's moronic brayings.
Thank you.
This has been a public service announcement.
This is to inform you, gentle moderator, that the parent post is from a person who has trolled Slashdot in the past under the names bonch and Overly Critical Guy. Please, do all of us a favor and don't be taken in by this person's moronic brayings.
Thank you.
This has been a public service announcement.
This is to inform you, gentle moderator, that the parent post is from a person who has trolled Slashdot in the past under the names bonch and Overly Critical Guy. Please, do all of us a favor and don't be taken in by this person's moronic brayings.
Thank you.
This has been a public service announcement.
This is to inform you, gentle moderator, that the parent post is from a person who has trolled Slashdot in the past under the names bonch and Overly Critical Guy. Please, do all of us a favor and don't be taken in by this person's moronic brayings.
Thank you.
This has been a public service announcement.
Yes, I agree with you that HTML must be mentioned. It is the most successful of GUI interfaces after all. And, Gosling is defying this success. File caching and fonts are left to the browser to optimize the use of bandwidth. HTML pages are incomparably preferable to PDF transmissions. As for improvement of the X protocol, whatever happened to the X compression methods where fonts were cached instead of being resent?
The future must resist this kind of reductionism proposed by Gosling. Instead, high extensions are needed for caching and parametric transforms, and for audiovisual channels, joysticks, and other kinds of telemetry.
Michael J. Burns
Twitter, you're a petulant cock-gobbling sycophant to Linux Torvaldyos! Quit taking DP from ESR and RMS's feculent cocks and why don't you try to stop sucking quite so much? Get out of your parents' basement and see the real world - maybe then you'll see how pathetic you sound, with your neverending stream of bullshit about how Microsoft is stalking you. Wasn't it you who said that Microsoft believes your insane ranting is actually a threat to them, so they PAY PEOPLE to reply to you on Slashdot? No sir, I don't get any money. I do it for the love. Someone has to go up against your paranoid whining. So get back in your cage and shut the fuck up already.
...I would patent it and then sue everybody else for having stolen my idea!
If I wanted to optimise my page size for the "best" sized read chunk from my hard drive (say, a full cache dump), how would I go about doing it in Linux? Is it possible? How could I benchmark it? Are page management schemes good enough that I needn't bother worrying about sequential page faults?
Inquiring minds want to know...
Dumbass mods, read the fucking timestamp.
Nice to have karma to burn.
Jay | http://oldos.org
A nice idea - giving userspace direct access to hardware, makes it all so simple.
.
Unfortunately basic security requirements interfere:
1) it MUST be possible for a user to type a simple key sequence and guarantee that as a result they will always be talking to the trusted OS
(ctrl-alt-del on wintel hardware does this with an interrrupt)
2) it MUST NOT be possible for an application to interfere with another applications data (including, but in no way limited to, font choices/definitions, window pixels, colour mappings)
So a TRUSTED component (either hardware or software) MUST enforce window offsets and clipping
Most COTS hardware does not include sufficient facilities to implement this and so it must be implemented with a trusted software module with exclusive HW access.
[ Obviously with minimal in-kernel support. ]
Goslings library model does not provide this,
and so is not a possible contender.
[ Hopefully future hardware will include more support for specific contexts allowing the software modules to be simplified, streamlined; perhaps to the extent of having a small cache of contexts and faulting if an uncached context is provided. ]
Right now I've got ~8 windows open on my Windows box, including File Manager, Outlook (for work email), Eudora (for my email), and a bunch of tabbed Mozilla browsers. I switch between windows fairly often, and I switch between tabs fairly often in the browsers I'm using. If you've got a rendering system that lets you download each one of those to the window server, and only refresh the parts of each hidden window that change, then yes, that's pretty rare, but if you need to refresh a whole screen whenever it you switch windows, that's a lot.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I'm not sure that I'd call what happened to it "marketing", exactly :-) Sure, there were some third parties like Grasshopper Group that actually tried to market ports of NeWS to various hardware, and there was Sun's hybrid "NeWS/X" stuff, but Sun really wasn't all that helpful, from what I remember.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I'm afraid I never gave Enlightenment a fair trial. I tried running it on a couple of machines with 64-96MB of RAM, and after a couple of attempts to do anything at all responded with the smoothness of Max Headroom on barbiturates, I backed it off and ran fvtwm, which performed adequately (at least for definitions of adequacy that includ fvtwm :-) (Basically, I'd rather have Sun Open Look on a Sparcstation 2 back....) And when we got a lot more RAM on the next budget cycle, I installed Gnome on some machines and KDE on others, and we ran Win2K and XP on the faster hardware...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Actually Gosling's is listed as one of the authors of JOptionPane, and his face appears along with the rest of the swing team in the killer swing demo (SwingSet).
BTW I like Swing as components are almost infinitely customizable. Statup time and memory could use some tuning though.
Don't be taken in by this idiot--he has accounts under the names bonch and Overly Critical Guy. He has a history of astroturfing for Microsoft, bashing anything Open Source, using lies and half-truths to get modded up, karma whoring, and the usual trolling (under his bonch account, he got a troll posted to the front page of Slashdot).
All you have to do to check the veracity of this is to look at the posting history of his two old personnae (linked above) and his current one to figure it out.
Please do not mod this jerk up--every time you do the Slashdot S/N ratio goes down while bonch/Overly Critical Guy/rd_syringe just laughs at you.
This has been a public service announcement