Shawn T. Rutledge writes:
> I don't think it's quite so hopeless. Just a matter of writing a lot
> of small methods for each level of rendering, each of which can be
> overridden by a method which goes direct to hardware if available. If
> you unit test each method, and then integration-test the pure software
> approach on a plain old framebuffer, then future problems are likely to
> be caused by bugs in the drivers rather than the graphics library.
. . . or in the hardware ;)
> But in the past the graphics library has not had methods for every
> possible operation, therefore new layers (like directX) had to be
> added on later. I think it's possible to "know better", and provide
> everything up front, at least every popular rendering technique that
> has been thought of so far. Well, I guess maybe a few years ago I
> wouldn't have predicted the "fog" features that are now being implemented
> in hardware on some cards...
I know fog has been discussed in high-end graphics circles for quite a while. But I'm no 3-D programmer. :)
> > EROS is already fairly radical compared to Linux or even the Hurd.
>
> Right. So I don't see much point in being in a hurry to get popularity
> at the expense of innovation.
EROS, in its present form, but with hardware drivers and Dionysix tacked on, could provide really significant benefits to those who are now Linux users. EROS burdened with an experimental GUI could fail because of the GUI. That would be a shame.
> Linux and MacOS-X and BeOS and such
> will probably keep the masses happy for quite a while, during which
> time the next big thing can be developed, whatever that turns into.
I don't want the masses to be happy. I want them to never suffer another ILOVEYOU virus.
> Unix had 25 years before it started to gain popularity on the kind
> of scale we see today.
Yeah. But five years after its first public release in 1975, it was the de facto standard for minicomputers, and pundits were voicing the view that it would shortly become the de facto standard for micros. Ten years after its first public release, it dominated the Internet and the workstation market and had started to squeeze out its competitors. Fifteen years after its first public release, it had no competitors. Except that it never got into the micro market.
Unix was able to do this because it suffered from no technophilia. It never did things in a complex way when a simple way would work most of the time. It was an egoless OS.
Linux, five years after its first public release in 1992, was already the de facto standard for new Internet servers. By ten years after its first public release, it will have dominated the Internet and the PC market.
EROS's first public release was in 1998; I would like to think its first useful public release will be this year.
> > > But, OpenGL might be a valid on-the-wire protocol to replace X. Maybe
> > > it would need some extensions for handling events from input devices.
> >
> > There is already an OpenGL implementation of X, so it meets my
>
> Yep. But I'm guessing that this was necessary because OpenGL itself
> is purely a description language
I said an OpenGL implementation *of* X, not *in* X. So if you have OpenGL, you can run X. ;)
If what you're saying is correct, then I must be wrong about that.
> Either API [Xlib or GDI] could be implemented to generate DPS code
> instead of X protocol. DPS can be used as an on-the-wire protocol, whereas
> xlib and GDI are APIs.
Xlib and GDI both have abstract imaging models behind them; they differ from each other's and from PostScript's. The mapping is not trivial, although of course it's mostly possible.
> But what do you think of using Scheme instead of Postscript,
> as a display language?
Scheme and PostScript are very similar languages. I think Scheme would be an excellent language to use. Implementing the imaging model is the really hard part, I think. Not that I know anything about that, of course.
> What I'm not clear on is if postfix notation (as in Postscript)
> has some advantage.
It's simpler and faster to parse, and the mapping between parsing and execution is very simple. GhostScript is in the same league of speed as RScheme, a rather fast Scheme implementation.
> I can see that Scheme interpreters are much more
> readily available than Postscript interpreters,
Scheme is a more popular programming language; it's easier to read :)
> and Ghostscript has a reputation for being hairy, brittle code.
GhostScript's reputation may have more to do with the author and the imaging stuff than the language.
-- <kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/> The Internet stock bubble didn't burst on 1999-11-08. Hurrah! <URL:http://www.pobox.com/~kragen/bubble.html> The power didn't go out on 2000-01-01 either. :)