[LispM-Hackers] Graphics questions

[James A. Crippen]

On Mon, 19 Mar 2001, John Morrison wrote:

> Hi (again);
> 
> "James A. Crippen" wrote:
> > I've been thinking about graphics display problems lately, after JM
> > mentioned them.  I think the best thing might just be to create our own
> > graphics abstraction and then port that abstraction to various display
> 
> I am presuming (hey ford & pf!) that the e2 wrote into a memory-mapped
> frame buffer which lived on the NuBus, right?  (I don't have the docs
> here with me at work, so I could be totally off-base here.)  Is access
> word/byte at a time?  Is there a graphics controller device?
> 
> If that is the case, do we not have a pretty well-defined graphics
> abstraction?

We might at one point (though not right now) want to write macroops to do
graphics instead of using the Lisp that writes to memory locations (if
that is indeed how it's done).  That would get us a portability layer for
free.  The simplest functions like TV:DRAW-SQUARE and the like could be
converted to direct macrocode calls.  Since just about all of the graphics
uses TV to do the dirty work that'd take care of almost everything, I
think.  But of course I'm not totally sure.

> > systems.  One could be written with some relatively flexible X widget
> > library like Qt, one could be GGI, one could be raw Xlib, etc,
> > etc.  Considering the wide variety of port targets this is most likely
> > going to guarantee maximum portability.
> 
> This makes sense to me.  I have personally used wxWindows (nice toolkit,
> nice do-what-you-will license) at the Day Job.  Runs on lots of
> platforms, and is layered upon (variously, depending upon version)
> win32, GTK, Motif, Xlib, and Mac (not that I care).

That might be good.  I'll have to look at it.  The last I saw of wxWindows
was when it was a pig and tended to depend on OpenLook, didn't work right
with Windoze, etc.  But that was a few years ago.
 
> We are pretty damned close to switching over to Qt at the Day Job (bunch
> of reasons)

Programmers who write gfx for X that I have talked to love Qt.  They
dislike most other toolkits.  So that's one thing in its favor.

> , but there are licensing issues (not that they absolutely
> apply to us, for I am only aware of the ones for commercial enterprises
> such as my Day Job).  Plus, Qt has an "embedded" version (royalties
> apply, I believe) which writes right into a frame buffer (for those
> hand-held devices based upon Linux).

Actually it might use SVGAlib, but I could be worng.

LibGGI also provides even more primitive functionality.  It basically
provides a smart framebuffer that can do things like squares, triangles,
fills, etc.  It's worth a close look although I'm not certain what it's
ported to yet.

> However, I don't believe either of these will enable you to, say, boot
> UNIX to text mode, and then startup e3 in the absence of X (I do not
> know whether we particularly care about this, but if our needs are
> really modest in terms of entry points and functionality per entry
> point, maybe this would be Cool and not too much trouble using SVGAlib
> or some such).

We could indeed just use SVGAlib directly.  But that's like using Xlib
IMHO, which is a PITA.  But I think that SVGAlib is cleaner than Xlib.

> Also, none of these help with Bare Iron.

Yup, and there it's totally dependent on the system.  That's going to be a
tough problem.

> > The only problem with an internal graphics abstraction is the cost in
> > speed.  I'd figure that we could get around this by making a large part of
> > the cost be amortized at compile time with the use of an ugly mess of
> > macros or suchlike.  But I don't have a concrete conception of
this yet.
> 
> The cost might become clearer if we had some idea of the graphics device
> we'd be simulating.  In the worst (from a performance point of view)
> case, it would be a completely dumb framebuffer -- but now, I'm
> speculating...  Who knows the answer?

Actually, I think it's a dumb framebuffer.  We just read memory and turn
it into graphics.  That's definitely suboptimal but I bet it was really
fast on the Exploder.

Hence my comment above, that we should (at some point after making the
dumb framebuffer work) extend the macrocode with some graphics primitives
such that we can expect something like TV:DRAW-SQUARE to call the macroop
DRAW-SQUARE which does something like e3Gfx::drawSquare().

'james

-- 
James A. Crippen <james@unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.