4 ms·

I used and wrote code for NeWS - the pre-curser for Java. I was also at the talk where Gosling admitted the problems it had. In some cases, a lot of features of

I used and wrote code for NeWS - the pre-curser for Java. I was also at the talk where Gosling admitted the problems it had. In some cases, a lot of features of Java were in response to the problems with NeWS. NeWS was so awesome when it came out, where you can dynamically change the interface at any time. But NeWS had some horrible bits. As a language, it was very hard to read. If you saw a name, you didn't know if it was a variable or a function. That is, you didn't know if the value would be pushed onto the stack, or if it would pop some values off the stack. Best Practice was to add a comment after each line to indicate what the top of the stack would look like after that line. So if you got lost reading one line, you could figure out what the next line would do. But without it, after seeing three words in a row that you didn't fully understand, you were hopelessly lost. NeWS (PostScript) was a write-only display model. You could not remove anything painted on the screen. You had to write over it. Adobe had Display PostScript, but that never took off. And because of the write-only display, NeWS had a hard time freeing resources. Garbage collection was very difficult because of this. You would allocate a white square, and never truly "remove it" from memory. As I recall, a page refresh had to re-interpret all of the code - there wasn't any caching of the window. Also - the entire display model with postscript-based scaling was CPU intensive, especially if you had a computer with slow graphics (quite common at the time).

DonHopkins 11y ago
PostScript uses an immediate mode state machine, kind of like GL, but a lot simpler. So there is a "graphics state", and while it contains a reference to the current font and accumulates a path as you draw it, there was nothing like a display list or object oriented graphics that would remember to draw a square and never get garbage collected. Laser printers typically had a linear heap based memory allocation system that let you ensconce and roll back all modifications on a page with save/restore, but NeWS never used that for anything practical (although it did support it in a weird inefficient way of recording and reverting all mutations, which was more for backwards compatibility so the PostScript previewer could rendering existing PostScript documents that used save/restore, and never used in any interactive user interface toolkit or app outside a PostScript previewer). Instead of a heap like a laser printer, NeWS used a reference counting garbage collection system, so once all references to an object were gone, it and any non-reachable sub-objects would be destroyed. To work around problem of circular references leaking memory, later versions of NeWS supported soft reference counts: each object would have both a soft and a hard reference count, and you could soften a reference if you wanted to hold onto an object but be notified when it was no longer otherwise accessible. Once all the hard references to an object went away, if the soft reference count was still not yet zero, it sent out a /Destroy event on that object which anyone holding a soft reference to it must be listening for, and they clean up their reference in response to, and it's only deleted once its soft reference count goes to zero. It's a weak reference [2], but it used NeWS's built-in event distribution system to notify reference holders (since there was no way of PostScript code to hook into the destroy callback of an arbitrary dictionary). Needing to use soft references directly wasn't very common in ordinary NeWS programming, and most uses were wrapped up behind the scenes by the toolkit (like the selection service listening for the selected object to be destroyed, text fields and menus pointing at each other for focus and pinned menu management, etc). NeWS canvases could have a backing store that you could enable or disable, and they could be retained off screen, and top level windows were usually retained. Technically it was just a hint and you always had to be prepared to repaint in response to a /Damage event, but all servers supported retained canvases, and it still made sense to turn off retained mode in the case of simple efficient graphics on 24 bit color displays. The art was in coming up with simple efficient ways of representing the data and generating the code doing the drawing in the server, so it could draw as fast as possible. Cool things were possible by dynamically generating PostScript code with inlined numbers, colors, fonts and other invariant parameters, in response to window resizing or layout changes and higher level data. You could inline calculated values into stupid-but-fast specialized instance methods (NeWS used a prototype based object system, that let you promote methods into instances), by using the PostScript equivalent of Lisp's "backquote" macro. [2] [1] Weak References: https://en.wikipedia.org/wiki/Weak_reference https://en.wikipedia.org/wiki/Weak_reference [2] TNT Slider Design Document: using PostScript "backquote" macro to cache efficient rendering code: http://donhopkins.com/home/archive/NeWS/tnt-sliders-design-2.txt http://donhopkins.com/home/archive/NeWS/tnt-sliders-design-2...
rthille 11y ago
"Adobe had Display PostScript, but that never took off." Well, except for it's use in NeXTStep. Though I think they threw it out in favor of PDF/Quartz for OS-X.

DonHopkins 11y ago

PostScript uses an immediate mode state machine, kind of like GL, but a lot simpler. So there is a "graphics state", and while it contains a reference to the current font and accumulates a path as you draw it, there was nothing like a display list or object oriented graphics that would remember to draw a square and never get garbage collected. Laser printers typically had a linear heap based memory allocation system that let you ensconce and roll back all modifications on a page with save/restore, but NeWS never used that for anything practical (although it did support it in a weird inefficient way of recording and reverting all mutations, which was more for backwards compatibility so the PostScript previewer could rendering existing PostScript documents that used save/restore, and never used in any interactive user interface toolkit or app outside a PostScript previewer). Instead of a heap like a laser printer, NeWS used a reference counting garbage collection system, so once all references to an object were gone, it and any non-reachable sub-objects would be destroyed. To work around problem of circular references leaking memory, later versions of NeWS supported soft reference counts: each object would have both a soft and a hard reference count, and you could soften a reference if you wanted to hold onto an object but be notified when it was no longer otherwise accessible. Once all the hard references to an object went away, if the soft reference count was still not yet zero, it sent out a /Destroy event on that object which anyone holding a soft reference to it must be listening for, and they clean up their reference in response to, and it's only deleted once its soft reference count goes to zero. It's a weak reference [2], but it used NeWS's built-in event distribution system to notify reference holders (since there was no way of PostScript code to hook into the destroy callback of an arbitrary dictionary). Needing to use soft references directly wasn't very common in ordinary NeWS programming, and most uses were wrapped up behind the scenes by the toolkit (like the selection service listening for the selected object to be destroyed, text fields and menus pointing at each other for focus and pinned menu management, etc). NeWS canvases could have a backing store that you could enable or disable, and they could be retained off screen, and top level windows were usually retained. Technically it was just a hint and you always had to be prepared to repaint in response to a /Damage event, but all servers supported retained canvases, and it still made sense to turn off retained mode in the case of simple efficient graphics on 24 bit color displays. The art was in coming up with simple efficient ways of representing the data and generating the code doing the drawing in the server, so it could draw as fast as possible. Cool things were possible by dynamically generating PostScript code with inlined numbers, colors, fonts and other invariant parameters, in response to window resizing or layout changes and higher level data. You could inline calculated values into stupid-but-fast specialized instance methods (NeWS used a prototype based object system, that let you promote methods into instances), by using the PostScript equivalent of Lisp's "backquote" macro. [2] [1] Weak References: https://en.wikipedia.org/wiki/Weak_reference https://en.wikipedia.org/wiki/Weak_reference [2] TNT Slider Design Document: using PostScript "backquote" macro to cache efficient rendering code: http://donhopkins.com/home/archive/NeWS/tnt-sliders-design-2.txt http://donhopkins.com/home/archive/NeWS/tnt-sliders-design-2...

rthille 11y ago

"Adobe had Display PostScript, but that never took off." Well, except for it's use in NeXTStep. Though I think they threw it out in favor of PDF/Quartz for OS-X.