On Tue, Jun 27, 2000 at 03:01:22AM -0400, Kragen Sitaker wrote:
> So for any particular optimization (mipmapping, say), you have at least
> three choices. You can ignore it, which means it doesn't get used, so
> it might as well not be there --- it doesn't help your performance.
> You can provide it in your display system, which means you have to
> write a software version for hardware that doesn't support it. Or you
> can provide access to it in your display system, but only on hardware
> that supports it, which means every single application that uses it has
> to make sure it's there and either use a substitute or die. This means
> your user applications become impossible to test.
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. 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... But everything else is old hat. They just keep finding faster ways to render polygon or spline-patch models with textures and lighting.
> Shawn Rutledge writes:
> > That's too old-fashioned, and EROS itself should concentrate on being the
> > best darn distributed-address-space capability system there is rather than
> > being good at everything like GNU/Linux-based systems try to do.
>
> I didn't know EROS had become a distributed OS. Are you thinking of E?
I didn't think it was either, but yesterday I thought I read something to
that effect... somewhere. I would like to see a method of aggregating
the memory spaces of a bunch of connected machines into one, and also
have transparent persistence. My primary interest in EROS is that it has
the last part. Aggregation can be done at a higher level; wouldn't
necessarily have to be an OS feature. (And minimizing access to
foreign memory space would be necessary in the real world to minimize
network traffic anyway.)
>
> 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. 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.
Unix had 25 years before it started to gain popularity on the kind
of scale we see today.
>
> > 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 (describing 3D objects or describing a "screen" or "page", depending on how you think of it) and doesn't include event stuff. glx is an X extension, so you don't normally get an OpenGL-only display without getting all the legacy parts of X along with it, AFAIK. I imagine that this would be considered an efficiency issue too... unless you can count on 3D acceleration hardware, it's not as fast to draw simple 2D windows using a 3D description of them. But doing everything in 3D would open up some interesting possibilities, and at some point the overhead won't matter anymore.
> (in an earlier email:)
> > GNUStep just runs on top of X, right? It's a framework, not a protocol.
>
> It runs on top of Display PostScript (or Display GhostScript), which
> can be implemented as an X extension or standalone. I also like
> PostScript much better than Xlib. However, many more portable current
> applications use Xlib. (Even more applications use Win32 GDI, but I
> think porting most of those applications is likely to be too
> difficult.)
Either API 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. So I would still start by trying to design
the perfect on-the-wire protocol for describing a GUI, and then
implement libraries to generate that protocol, rather than saying that
there can only be one graphics API. If you always show graphics on
the same box as you run the apps on, it doesn't matter (as in Windows'
case, until recently). If you want client-server functionality then
the protocol is the most important part of the design. It also lets
you ignore the rendering issues and leave them up to the client.
(well, the "server" in the X sense of the word...)
>
> This is a very hard research problem. Making the success of one's
> software dependent on solving a very hard research problem
> significantly decreases the chances of its success.
>
> I think this is a very interesting project, and I will certainly watch
> metawidgets.org when you build it. I just don't think it should be
> adopted as the standard EROS drawing toolkit until after it is proven :)
Fair enough.
But what do you think of using Scheme instead of Postscript, as a display language? The more I think about it the more I think it would be much more useful than XML... one language to handle high-level metawidgets as well as the implementation of them and the client-side behavior. What I'm not clear on is if postfix notation (as in Postscript) has some advantage. I can see that Scheme interpreters are much more readily available than Postscript interpreters, and Ghostscript has a reputation for being hairy, brittle code.
Someone else made the point that access to a display system is a "capability"; that's well taken also, I hadn't thought about security too much yet. It seems like a good fit though.
-- _______ Shawn T. Rutledge / KB7PWD ecloud@bigfoot.com (_ | |_) http://www.bigfoot.com/~ecloud kb7pwd@kb7pwd.ampr.org __) | | \________________________________________________________________ Get money for spare CPU cycles at http://www.ProcessTree.com/?sponsor=5903