Richard wrote:
In article <48E48C7B.8020007@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
Might be true of the DOS version. XFractint is using my much more modern graphics cards through the X video system, so I doubt that it's using any legacy compatibility codepath ...
True, but its still not using the card any smarter than treating it as a dumb frame buffer.
Actually, I think it is. Unlock dear old DOS Fractint, it happily renders in a graphical window on my Linux desktop - so it is clearly NOT using the card as a "dumb frame buffer". It's rendering graphics to an image window managed by the X video system, which is just another chunk of system memory.
I bet Fractint spends much more of its time calculating numbers than it does accessing the video card, anyway.
True, but DOS fractint is *also* using the slow compatability path on the CPU.
True. It still calculates far more numbers than it makes video accesses.
I can't imagine how Fractint could possibly use many of the "newer" features (3D acceleration and game-oriented stuff). Perhaps it could offload processing code to a modern GPU?
There are lots of things fractint could do with the features of a modern video card. Some fractal computation can be GPU based making the computation scream orders of magnitude faster than what fractint can do now.
Very true! Someone just needs to factor Fractint into two parts - a back-end processing engine (platform independent, compile and run on any hardware including a GPU, the supercomputer down the street or a render farm of commodity PC hardware) and a standard, documented API for accessing the processing engine. (Including over the network, hurrah for the built-in networking friendliness of X Windows!). And, of course, recode Fractint to support 32-bit color (RGBA) for some really neat transparency renderings .. Then someone could write a Javascript front end and we could have Web Fractint! ;-) -- David gnome@hawaii.rr.com authenticity, honesty, community