NeWS (ex 80s SunDew): was/is better than x11? does it deserve resurrection?

[DiTBho]

So, NeWS stands for "Network extensible Window System" is a discontinued windowing system developed by Sun Microsystems in the mid-80s.

I seriously *hate* Sun Microsystems for their crappy SPARC architecture (specifically I don't like the window registers, because it makes debugging hell), but I have to admit NeWS was a good idea.

NeWS started by implementing a PostScript interpreter, then added a complete view hierarchy, and a complete model for events, including timers and other automatic events, input queues for devices such as mice and keyboards, and other functionality required for full interaction, so the input handling system was designed to provide strong event synchronization guarantees that were not possible with asynchronous protocols like X.

This means, NeWS was potentially better than X11 ... unfortunately slower due to bad implementation, and badly managed at the business level.

What is bad is that NeWS is based on PostScript, it talks PostScript, it's mostly programmed in PostScript, and for sure, you don't want to debug Postscript because it's too difficult hence to prone to carry bugs. But ... looking at the whole concept, how events are managed and handled, damn, it's not that bad and it could be rewritten in pure C nowadays, in a modern, compact, clean way.

[PKTKS]

Postscript has the utmost steep learning curve of all...

You rather just have a Gks interface made for postscript in ghostscript tools...

They are a hell to deal with

Paul

[newbrain]

NeWS was so resource-heavy on the machines of the time (early '90s for me) that it was impossible for me to use, as I needed some near RT performance.
It was a project to generate simulation data and control a high speed data recorder for later faster playback on a dedicated HW signal generator.

SunOS with regular X11 was so much better in not hogging memory and CPU while still running a nice GUI that it was possible to a limited extent to generate useful real time data, skipping the recording/playback step, generation jitter was not an issue, as it was taken care by the HW (FIFOs + time stamped data).

That said, it was fun to send postscript drawings directly to the screen, especially to that of coworkers.

[bd139]

This concept is used all over the place and no one realises it.

Look at Apple Quartz which is the main display compositor in macOS. https://en.m.wikipedia.org/wiki/Quartz_(graphics_layer)

Incidentally that’s why doing stuff with PDFs on macs is so much more pleasant.

macOS is basically all the best bits of various unixes fudged into one blob that works properly. Oh and it’s actually a certified unix too. Winner winner chicken dinner.

[DiTBho]

what would you use to replace the Postscript interpreter?

[bd139]

https://developer.apple.com/documentation/pdfkit

Only for documents. I'd write stuff in some other language and forget it all exists 

[DiTBho]

They are a hell to deal with

Yup, nobody "sane" would write a PostScript interpreter these days, and most of the old ones have vanished into the mists of history.

[DiTBho]

When Steve Jobs left Apple and started NeXT, he pitched Adobe on the idea of using PS as the display system for his new workstation computers. The result was Display PostScript, or DPS. DPS added basic functionality to improve performance by changing many string lookups into 32 bit integers, adding support for direct output with every command, and adding functions to allow the GUI to inspect the diagram. Additionally, a set of "bindings" was provided to allow PS code to be called directly from the C programming language. NeXT used these bindings in their NeXTStep system to provide an object oriented graphics system. Although DPS was written in conjunction with NeXT, Adobe sold it commercially and it was a common feature of most Unix workstations in the 1990s.

Sun Microsystems took another approach, creating NeWS. Instead of DPS's concept of allowing PS to interact with C programs, NeWS instead extended PS into a language suitable for running the entire GUI of a computer. Sun added a number of new commands for timers, mouse control, interrupts and other systems needed for interactivity, and added data structures and language elements to allow it to be completely object oriented internally. A complete GUI, three in fact, were written in NeWS and provided for a time on their workstations. However, the ongoing efforts to standardize the X11 system led to its introduction and widespread use on Sun systems, and NeWS never became widely used.

From the Wiki, see here for the two approaches!

[Nominal Animal]

It would be an interesting research project to consider a compositor using SVG or a binary representation thereof.
That is, the UI would be defined in terms of (a subset of) SVG elements and not pixmaps like they are in X11.  Data flowing between an application and the display would be in terms of SVG visuals and not pixmaps (and of course UI event descriptions).

The display server would require a fast/efficient SVG rasterizer for the actual framebuffer, of course.

In terms of efficiency, the compositor approach really depends on the available display hardware.  X11 was designed in an era where displays had bitmap (BW) or pixmap-based framebuffers, and basically no acceleration, so everything had to be done in software.  This is also why basically none of the current approaches really take full advantages of the hardware capabilities: the hardware has leaped forward, but the software is still much the same.

[bd139]

SVG parsing snd rendering is terribly slow and CPU intensive so I’m not sure I’d want that.

There’s a mid ground somewhere which bridges how the hardware works and how humans thing without too many compromises on either side. We haven’t found it quite yet. Most of what we have errs towards humans with lots of bitmap caching at the moment.

[DiTBho]

The display server would require a fast/efficient SVG rasterizer for the actual framebuffer, of course.

aren't GPUs extremely good nowadays for a fast/efficient SVG rasterizer?

[Nominal Animal]

The display server would require a fast/efficient SVG rasterizer for the actual framebuffer, of course.

aren't GPUs extremely good nowadays for a fast/efficient SVG rasterizer?

No, not really.  SVG is a bit too abstract, a bit too high-level.

You do need things like quadratic and cubic curves, though.  They would be best rendered with pixel shaders, and not as vertex geometry, though.  (Basically all fonts we use now are defined in terms of line segments and quadratic and cubic curves.)

It'd take quite a cross-disciplinarian to find out a good descriptive format.  That's why I wrote "a subset of SVG elements".

For example, if you want to draw a circular dot, you can do so quite fast by setting up a triangle or a rectangle that covers the dot (including any antialiasing region), and then use a pixel shader to draw the actual dot, using either cartesian (∆x²+∆y²≤r²) or texel/barycentric coordinates (the form of which depends on the exact shape of the triangle used).  Right now, this sort of techniques are used to draw a very large number of semi-transparent spheres/spheroids for real-time particle effects, for example.

In other words, implicit equations for 2D shapes might yield good results.

[DiTBho]

so, the answer to the question in the title of this topic is: no resurrection, let it rest in peace.

R.I.P.
NeWS