I'm going to really show my age here. Back when I was doing my Masters degree at the University of Saskatchewan (now there's a Canadian word that's hard to say even for Canadians), I was doing graphical representations of software models. Yes, my modeling roots go back 20 years. Essentially, I was trying to come up with a generalized diagramming model that could represent different modeling languages.
When it came time to do the prototype, I had a choice of windowing systems that ran on our Sun and HP boxes we had in the lab. Of course, we had X Windows, X11R2 if I remember correctly which was much better than X10.
We also had this new system from Sun called the Network extensible Window System. It was wacky but very cool and had a wacky and cool acronym, NeWS. Essentially you programmed the window server using PostScript (of all things) that was extended by Sun to handle windowing and input devices and asynchronous communication back to the client. It was quite bizarre to be writing PostScript code to do UI but it was a good way to separate UI from Core with an efficient protocol you got to create yourself to best suite the application.
Unfortunately, the implementation was very slow and awkward and the co-operative multi-tasking made it impossible to debug endless loops (but it did help me learn the Sun equivalent of Ctrl-Alt-Dlt). I eventually picked X Windows and this wacky new language called C++ and the rest is, well, even more history.
What NeWS reminds me of today is this whole concept of Web 2.0, and Flash/Flex in particular. And not because PostScript and ActionScript have the same suffix, but because the architecture is very familiar. And it made me wonder if we could use it in the same way, as a windowing system. I can't remember how I programmed the C side but if we used a similar API and protocol would it be any good? Now if I can only find some 20 year old documentation to find out.
"X Window" not "X Windows" :)
ReplyDeleteNeXT's Nextstep used display postscript for its UIs and now MacOSX uses DisplayPDF. Sadly, whilst you could do remote displays with -host in Nextstep, you can't do the same with MacOSX, though that's probably due to the optimisations in Quartz Extreme than anything else.
ReplyDeleteI have been using NeWS on a sun3 in the mid 80ies and I don't remember that it was slow. When I then saw X, I thought what a step back!
ReplyDeleteUsing (gtk) eclipse over a 1000mbit Ethernet *is* much slower than NeWS was 20 years ago on a 10mbit network. There is way too much communication going on between client and server. NeWS was quite good at minimizing the communication. This does not mean X is slow. It just means GTK and eclipse do bad things.
Our old product SNiFF (based on Erich Gammas and Andre Weinands ET++) was also running on X but it used X very efficiently. I was able to run eclipse remotely over an ISDN line. Now I have a 16mbit Internet connection and I cannot run eclipse remotely. Some years ago I did an analysis and I figured that ET++ was very good at caching information about the display. E.g. it kept the measurement of the fonts in the application. GTK eclipse asks the display thousands of times to measure some text. Those are synchronous calls and if the network latency is long you are lost.
ET++ on the other hand asked for the font measurement once and did all the calculation on in the application and then pushed the drawing operations to the display without asking much.
The choice is: either do the layout calculation and rendering in the display OR do it in the application. The worst case is to do it in the application by constantly asking the display.
According to all the Smalltalker's around the Eclipse community, all this shit we do has been already done in Smalltalk (in one form or another)
ReplyDeleteYou are correct Michael. Actually only the initial startup was slow. Having more smarts on the window server side really does improve performance especially across a network wire.
ReplyDeleteThis is really where I'm coming from. I hate X exactly because of it's horrible low level protocol. It disturbs me to see X running on embedded devices. Architectures like this may make things cleaner. Interesting to look at anyway.