[LispM-Hackers] Graphics questions

[John Morrison]

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?

> 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).

We are pretty damned close to switching over to Qt at the Day Job (bunch
of reasons), 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).

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).

Also, none of these help with Bare Iron.

> 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?

> I do know that we're fast approaching the point where we will want to at
> least do some textual graphics for initialization.  This will probably
> become a major problem.
> 
> I might go look at how some of the game system emulators do this,
> particularly those that are highly portable.  I don't know if any are
> actually ported to systems other than Windows and Linux, but I suppose
> there's at least one or two out there that are.
> 
> I particularly don't want to become entirely dependent on one library for
> all of our graphics needs, especially one which is only ported to a small
> handful of platforms.  This needs some heavy thought though.  Does anyone
> have any suggestions or previous experience?  Any graphics libraries that
> they're familiar with or at least know of?

What I said above...

-jm

-- 
==== John Morrison
==== MAK Technologies Inc.
==== 185 Alewife Brook Parkway, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== jm@mak.com