Quo vadis GRX?

[Frank Heckenbach]

(This is a reply to a mail in the gpc at gnu.de list.)

Thanks for bringing up GRX as well. Since it seems it is not used
much apart from with GPC anymore, this is probably quite related.

However, since GRX has its own mailing list (grx at gnu.de),
I'm cross-posting and setting "Reply-To" there.

Maurice Lombardi, the current GRX maintainer, should be reading both
lists, and I hope he will comment.

twixt at cstone.net wrote:

> I would like to use Pascal to generate images in high resolution and at
> least 24 bit color depth. There are links to a GRX library, which provides
> 2d graphics, but the user manual there was last updated in 2007, which
> suggests they are further behind than GPC. I don't find any grx library in
> my Debian (Lenny) list of available packages, using the search feature
> within aptitude. Apparently I would have to compile GRX and then somehow
> get it to work with Pascal. As a barely capable programmer, I do not look
> forward to this with glee.

Compiling GRX, especially under Linux, should not be terribly
difficult (try the docs first, then ask on the GRX list if
necessary). However, it is a bit dated, only getting bug fixes and
small changes for the last years (well, like GPC), and I suspect its
future is dependent on GPC's future, too.

I've used GRX for lightweight graphics progams (including some
ported from BP, thanks to its "Graph" unit), but I'm not using it
for any new projects now.

For some high-performance graphics programs I did recently I used
OpenGL (though in C++ -- AFAIK, there is no GPC interface
available), which among other things supports hardware-accelerated
graphics which is a must for high performance graphics today, and
which GRX doesn't do AFAIK.

> How about incorporating graphics
> output directly in Pascal? Is there much interest in this? It seems to me
> that it would make Pascal more attractive.

I'd strongly suggest against that. In general, tying libraries
tightly with languages is a bad idea IMHO. Of course, GPC has a set
of runtime and add-on units, though actually rather small compared
to other current environments; even more so in C -- libc contains
rather basic stuff (and even it can be replaced, e.g. in OS kernels
or emebdded systems), and all the higher-level libraries are not
part of or specified by the language, but strictly users of the
language. As a side note, that's IMHO a major reason for the success
of C -- being library-neutral it can (not necessarily should) be
used for just about anything. The same is true almost as well for
C++ (STL mostly adds data structures and algorithms which do not
depend on a certain environment) and to a slightly smaller degree
for Pascal (in particular the I/O system, which is part of language,
would have to be "cut out" in certain environments), but much less
for Java and other languages that are dependent on big "frameworks".

One reason why I think languages should not be coupled to libraries
is that many kinds of libraries have a much shorter life cycle than
programming languages (should have). The latter is measured in
decades, the former often in years (at best). This is especially
true of graphics, where we don't even a universally accepted
standard today (let alone one that we could reasonably expect would
still be the standard, say, 20 years from now) -- in my view, only
OpenGL would be a candidate (if high-performance graphics is
included; if not, there are various alternatives), but I'm sure
others will disagree.

Furthermore, as you can see from my comments, there's even a big
difference stemming from which kind of graphics you want to support.
Again, for high performance you need something that supports
hardware acceleration; for simple graphics on cheap hardware, this
can be a bad choice. E.g., though there exists a free
software-implementation of OpenGL (Mesa), which works reasonably
well IMHO (IOW, not too bad, but not perfect) on
non-hardware-accelerated cards, but since it has to cater for the
general case, simple things are often slower than in simpler
libraries that specialize on such things. And of course, 2D graphics
is quite different from 3D vector graphics which are both quite
different from raytraced graphics.

> It would be "like POVray
> but even more powerful" as any general purpose programming language
> naturally would be. Thanks for your time.

This is also the case if you make it a stand-alone graphics library,
which could then be driven from Pascal programs instead of POVray
programs (if there's demand for it -- I don't know, I'm not much
into raytracing).

Frank

-- 
Frank Heckenbach, f.heckenbach at fh-soft.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 0FE0 E5E8