(This is a reply to a mail in the gpc@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@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@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